Encode to Base64 format

Overview

Base64 is a reversible shape shift, and this tool is the forward half of the trip: it takes anything you can type or any file you can upload, and rewrites it into the printable text that survives emails, URLs, and JSON documents without losing a single byte. Paste some data, pick your flavor of Base64, and the encoded result is ready to copy. The matching decoder lives on the sister site, one link away.

Advanced options

• Character set: Your text always reaches us as UTF-8, and by default it is encoded as UTF-8. Change the list when the other end expects different bytes, say Windows-1252 for a legacy Windows program or an ISO-8859 variant for older European software: the conversion happens before the encoding, so the string you get carries exactly the bytes you asked for. Tell the decoder which set you picked, because Base64 itself never says. In the file form the list starts at BINARY (no conversion), the right choice for everything except plain text.
• Newline separator: Unix and Windows disagree on how to end a line, and your input may carry either (or both). Before the encoding starts, every line break in the text is rewritten into the style you pick here, so the encoded payload is consistent no matter where the data came from. The same separator also joins the output lines when one of the two multi-line options is on. For uploaded files the bytes are left as they are; the separator only decides how the encoded output is broken into lines.
• Encode each line separately: Normally the whole input is encoded as one block, line breaks included, which is what most applications expect. Enable this when the input is a list of independent entries instead: each line is encoded on its own, and the encoded lines are joined back together with the separator you chose. (*)
• Split lines into chunks: A fresh Base64 string is one long line, which suits most systems but not all: the MIME specification (RFC 2045) says encoded lines should be no more than 76 characters, and email in particular wants them short. Tick this box and the output is wrapped at 76 characters per line, using your chosen separator. (*)
• Perform URL-safe encoding: Two characters of the standard alphabet, + and /, do not sit well in URLs, and the = pads make things worse. This option switches to the Base64URL variant from RFC 4648 instead: + becomes -, / becomes _, and the pads are dropped entirely, because they can be worked out from the length. The result is shorter and safe to drop into URLs, filenames, and JSON Web Tokens without any escaping. Just remember to tell the decoder which dialect you chose.
• Live mode: Flip this on and the encoding happens in your browser as you type, re-running on every keystroke with nothing sent to our servers. It honors the other options, per-line, chunks, and URL-safe, as you toggle them, and it works with UTF-8 only, so the character set list stays locked while it is on, and the encode button stays disabled until you switch back.

(*) These options cannot be enabled simultaneously, since the resulting output would not be valid for the majority of applications. The form takes care of it: checking one disables the other.

Safe and secure

Everything runs over an encrypted HTTPS connection, and nothing you submit is kept: uploaded files are deleted the moment they are processed, and the downloadable result disappears right after your first download attempt or 15 minutes of inactivity, whichever comes first. The contents of what you send are never stored or looked at beyond the conversion itself. With live mode on, your text never leaves the browser. The full details live in our privacy policy, linked in the footer below.

Completely free

Everything on this page is free to use - the complete character set list, the file uploads, and the live mode included. No account, no software to install, no paywall: for a task this small, that is how it should be.

Base64 explained

Some data simply cannot travel through a text-only channel: a photo, an archive, a hash, a chunk of binary that would make a 7-bit email connection choke. Base64 is the translator for moments like this. It rewrites any sequence of bytes into plain, printable text, so the data can sit in an email body, a JSON document, an XML file, or a URL and arrive exactly as it left. The translation is fully reversible: every byte comes back, in the same order, with nothing lost along the way.

The whole format fits in one sentence: three bytes in, four characters out. The price is a result that is about a third bigger than the original. The reward is a string that looks like text, behaves like text, and survives channels that would destroy raw bytes. And it is worth pinning down early what Base64 is not: it is not encryption, and it is not compression. It is a reversible shape shift, and that is the entire job.

Why 64, and why those characters

A byte holds 8 bits, but old text channels, email above all, only carried 7-bit ASCII safely. The trick is to pick an alphabet of printable characters that survives any such trip, and to size it so the math comes out clean. With 64 characters, each encoded character carries exactly 6 bits, and 24 is divisible by both 8 (the byte) and 6 (the character): three input bytes become four output characters with nothing left over. The name is just the base of that character math, like base 10 for our digits.

The standard alphabet is the 62 alphanumeric characters, A to Z, a to z, and 0 to 9, with + and / as the last two. The specification adds a 65th character, =, which is not in the alphabet at all: it only ever appears at the end, as padding. The choice was deliberate. The whole set is printable; it is common to every text system; and the MIME specification notes that it is spelled identically in every version of ISO 646, including US-ASCII, and in every version of EBCDIC. That last property is what keeps the data intact while it crosses the old 8-bit-unclean machinery of the internet.

Encoding, step by step

The encoder is a four-step assembly line. It reads the input three bytes at a time and merges each triplet into a single 24-bit string. That string is cut into four chunks of 6 bits. Each chunk is a number from 0 to 63, and each number is looked up in the table above. Four numbers in, four characters out.

Watch it happen on the word foo, which arrives as the byte values 102, 111, and 111 (hex 66, 6F, 6F). Laid end to end, the 24 bits are 01100110 01101111 01101111. Cut into sixes, that is 011001, 100110, 111101, and 101111, which are 25, 38, 61, and 47. The table says those are Z, m, 9, and v, so foo encodes to Zm9v, and any Base64 decoder in the world will turn it back into the original three bytes.

The rest of the input is processed the same way, triplet after triplet, until nothing is left. Only the final group, when it holds fewer than three bytes, needs a special move.

Padding: the = at the end

The input is always a whole number of bytes, but three does not always divide it evenly. When one or two bytes are left over at the tail, the encoder still has to finish a full group of four characters. It fills the missing bits with zeros, does the lookups as usual, and replaces the characters the padding bits would have produced with = signs. Exactly three endings are possible:

So fo, two bytes, becomes Zm8=, and the lonely f becomes Zg==, while foo needs no padding at all. The decoder knows exactly what to do with the pads: each = means eight more zero bits to throw away. The pads only ever sit at the very end, and there are at most two of them. The MIME spec even uses this as a feature: since = cannot appear anywhere else, a padded payload announces its own ending, so the receiver can tell the data was not truncated in transit. And for the smallest case: the empty input encodes to the empty output. Even nothing gets a perfect round trip.

Decoding: the assembly line in reverse

Decoding is the same machine running backwards, and it is just as mechanical. Take four characters, look the real ones up (a pad stands in for six zeros), write out the 24 bits, and hand back the first 16 bits if one pad is present, or all 24 if there are none. Four characters in, three bytes out; two bytes out with one pad; one byte out with two. The zero bits the encoder added are the only thing thrown away, and every other bit is exactly what went in. That is what reversible really means here: the format itself is lossless, and the only things that can hurt your data are a channel that corrupts the string, or a decoder that quietly gives up.

That is why the standard is strict about one thing: characters that are not in the alphabet. RFC 4648 says a decoder must reject a payload that carries any character outside the 64, unless the surrounding specification explicitly allows it. The reason is practical, not pedantic. A decoder that quietly swallows foreign characters can be tricked: the smuggled characters become a hidden side channel, and that trick has been used to hide data from filters and to poke at decoder bugs. The famous exception is MIME itself, which predates the standard and says the opposite: ignore every character outside the alphabet, and that is how the line breaks get through an email attachment. When you validate input yourself, the modern rule is the right one: if your string carries an @, a space, or anything else that is not in the table, it is not clean Base64.

Line breaks and the 76-character rule

You will often meet Base64 wrapped into lines, and the habit comes from email. Old SMTP machinery had line-length limits, so MIME wraps the payload at 76 characters per line with a CRLF break, and the older PEM format, the one that carries certificates and keys, wraps at 64. RFC 4648's rule for new code is the opposite: add no line breaks at all unless the format you are implementing says to. In practice, the decoder does not care. A line break is just a character outside the alphabet, so a MIME-wrapped payload, a PEM block, and one long unbroken string all decode to the same bytes. If you paste Base64 from anywhere, strip the line breaks first and be done with it.

The wrapping has a small cost, and it shows up in size math. Without line breaks, Base64 is exactly four thirds of the original, about 33 percent bigger. Wrapped at 76 characters with CRLF breaks, it is about 37 percent bigger, which is why a file that should be 100 KB often arrives as roughly 137 KB of text. The math always checks out.

Base64URL: the URL-safe twin

The standard alphabet has two characters that do not play well with URLs. A + in a query string is traditionally read as a space, and / is a path separator, so a raw Base64 string in a URL needs percent-escaping for both, plus the = pads. Section 5 of RFC 4648 defines the fix: the URL and filename safe alphabet, where + becomes - and / becomes _. The pads usually go away too, because a missing pad can be worked out from the length. The RFC says flatly that this should not be called plain Base64: it is a different encoding, usually written base64url.

In practice, the two are one swap apart, in the dangerous direction. Feed a base64url string to a standard decoder and it goes wrong, because - and _ are not in the standard alphabet: a lenient decoder discards them and returns a shorter, wrong byte string - or, when the remainder is too short to stand alone, an error - while a strict one rejects the whole payload. The correct dance is to swap - back to + and _ back to /, top up the missing pads, and only then decode. This is the dialect you meet in JSON Web Tokens (JWT), OAuth state strings, and the IDs of a certain very large video site.

A quick field guide

Before you reach for a tool, you can read a lot of the string yourself. A few checks tell you whether a payload is Base64 at all, and what it hides:

• Look at the characters. Standard Base64 uses only A to Z, a to z, 0 to 9, +, and /; the URL-safe twin uses - and _ in place of those two. Any other symbol, or a stray space, means it is not clean Base64.
• Check the pads. The = signs, if present, sit only at the very end, and there are at most two. A pad in the middle of the string is a red flag.
• Count the length. With pads, the length is always a multiple of 4. Without pads, dividing the length by 4 leaves a remainder of 0, 2, or 3. A remainder of 1 is impossible, because a single character only carries 6 bits and a byte needs 8.
• Estimate the size. Each group of 4 characters holds 3 bytes, minus one byte per = sign. So Zm9vYmFy, eight characters with no pads, is 6 bytes, and Zm9vYg==, eight characters with two pads, is 4.

One last field trick, and the most useful. The encoder must zero the padding bits, but a lenient decoder does not check them. The payload Zg== decodes to the single byte f, and so does Zh==: the low bits of the last character are padding in both cases, so both spell the same byte. The standard calls the zero-bit version the canonical form, and it lets strict decoders reject the other one. Two strings, one payload. If two systems disagree about a Base64 value, the pad bits are a good place to start looking.

What Base64 is not

• Not encryption. There is no key and no secret; anyone can turn a Base64 string back into bytes in a second. The RFC even mentions real incidents where people reported protocol exchanges that included an "encoded" password, convinced the encoding was hiding it. If the data is sensitive, protect it with real cryptography before you encode it, not after.
• Not compression. It goes the other way: the result is about 33 percent bigger than the input, and larger still once line breaks are added. Base64 buys you text safety, and it bills you for it in size.
• Not a character set. Base64 moves bytes, not letters. It does not know or care whether those bytes are UTF-8 text, a legacy one-byte encoding, or a JPEG. The "which charset is this?" question lives before the encoding and after the decoding, never inside it.
• Not one single encoding. The name covers a family: the standard alphabet, the URL-safe twin, payloads wrapped at 76 or 64 characters, variants that skip the pads, and a handful of oddballs (IMAP, for instance, uses a comma in place of the alphabet's / when encoding international mailbox names). When two systems disagree on a payload, a dialect difference is usually the culprit.

The fine print

The primary sources are short and readable. RFC 4648, The Base16, Base32, and Base64 Data Encodings (2006), is the current standard: both alphabets, the padding and line-break rules, the strictness rules, and a set of official test vectors, like foo becoming Zm9v, that implementations check themselves against. Behind it stands RFC 2045, the 1996 MIME specification where the 76-character line rule and the ignore-stray-characters leniency come from, and RFC 1421, the deprecated Privacy Enhanced Mail spec that started the family with 64-character lines. An earlier unification attempt, RFC 3548, was replaced by RFC 4648.

That is the whole story: 64 characters, three bytes in and four characters out, = to finish the tail, and a perfect round trip. Every tool, library, and online converter you will ever meet is just a doorway into this. Once you can look at a Base64 string and see the bytes standing behind it, nothing about the format surprises you anymore. And when you are ready to write the encoder yourself, the programming-language articles just below this section hand you the same 64 characters as working code: one complete guide per language.