Why exactly 64 characters and not 128?

Because 64 is the largest power of two that fits safely in every character set ever used for mail and text protocols. Six bits map to one character, and six divides evenly into 24, so three bytes become four characters with nothing left over.

What happens if I strip the equals signs?

Some decoders cope and some refuse. The padding tells a strict decoder how many bytes the final group really held, so removing it makes that group ambiguous. base64url drops padding by design, which is why its decoders infer the length instead.

Is Base64 the same on every platform?

The alphabet is, but line wrapping is not. The MIME spec wraps at 76 characters, PEM wraps at 64, and most programming libraries wrap at none. Same characters, different newlines, and that difference breaks naive string comparisons.

Does Base64 protect data in any way?

No, and treating it as protection is a real security mistake we still see in production. Anyone can reverse it in one click with no key and no effort. It is a transport format, not a lock.

Why does the size increase by exactly 33%?

Because four characters carry three bytes, and four divided by three is 1.333. Padding adds up to two more characters at the very end, which is negligible on anything but tiny inputs.

Can Base64 encode text as well as binary?

Yes, but text has to become bytes first, and that is where tools break. The browser btoa function only accepts Latin-1 characters, so any emoji or non-Latin script throws an error. Convert to UTF-8 bytes first.

What is Base32, and why would anyone use it?

It uses 32 characters and avoids anything case-sensitive or easily confused, like the digit one and the letter l. That makes it readable aloud and safe in case-insensitive systems such as DNS. The cost is a 60% size increase instead of 33%.

Why do some Base64 strings start with the same characters?

Because the file header does. Every PNG begins with the same eight bytes, so every encoded PNG begins iVBORw0KGgo. That predictability is exactly what file-type detectors rely on.

The maths is trivial, but the memory is not. Encoding needs the original data plus a string a third larger in memory at the same time, so large files hurt far more than the arithmetic suggests.

It grew out of the Privacy-Enhanced Mail work in the late 1980s and was formalised for MIME in RFC 1341 in 1992. The current definition lives in RFC 4648. It has outlived nearly every protocol it was designed for.

What Is Base64 Encoding? A Plain-English Explanation

Someone hands you a string of gibberish and calls it a file. You paste it somewhere and it breaks. Nobody explains what it actually is, only that you need it. Base64 is simpler than it looks, and ten minutes here will save you hours later.

What Is Base64 Encoding? The Short Answer

Base64 rewrites binary data using only 64 safe text characters, so it can travel through systems that only understand text.

That is the whole idea. Email bodies, JSON payloads, HTML attributes, and URLs were all built for text. Hand them raw binary and something in the chain mangles it.

Base64 solves that by translating. Nothing is compressed, nothing is hidden, and nothing is lost — the data is just written differently.

Want to try it while you read? Our Base64 encoder and decoder runs entirely in your browser.

How Base64 Works, Three Bytes at a Time

It regroups the bits. Computers store data in 8-bit bytes. Base64 ignores those boundaries and re-slices the same bits into 6-bit chunks.

Take three bytes: 24 bits. Cut that into four 6-bit pieces. Each piece is a number from 0 to 63, and each number maps to one character.

Three bytes in, four characters out. That ratio never changes, which is where the 33% size increase comes from.

Here is "Cat" going through it:

Text:    C          a          t
ASCII:   67         97         116
Binary:  01000011   01100001   01110100
Regroup: 010000 110110 000101 110100
Values:  16     54     5      52
Base64:  Q      2      F      0

So "Cat" becomes "Q2F0". Run it backwards and you get "Cat" again, exactly.

One thing worth noticing: the 6-bit groups cut straight across byte boundaries. That is why you cannot decode a Base64 string starting from the middle — you would land between characters.

The Base64 Alphabet, All 64 of Them

Twenty-six uppercase letters, twenty-six lowercase, ten digits, then plus and slash.

Values	Characters
0 to 25	A to Z
26 to 51	a to z
52 to 61	0 to 9
62	+
63	/

Those last two are the troublemakers. Plus and slash both have special meaning inside URLs, so a Base64 string pasted into a query parameter can break in ways that are painful to trace.

That is why a URL-safe variant exists, swapping them for dash and underscore. We cover the differences in base64url versus standard Base64.

Why Base64 Padding Uses Equals Signs

Because your data rarely divides neatly by three.

Base64 works in groups of three bytes. When the last group is short, the encoder pads it and marks how much padding it added.

Three bytes left over — four characters, no equals sign.
Two bytes left over — three characters plus one =.
One byte left over — two characters plus two ==.

This gives you a free integrity check. A valid Base64 string is always a multiple of four characters long. If yours is not, characters went missing.

In our experience that single rule explains most "corrupted" strings people bring us. The data was fine; the copy was cut short.

Base64 vs Encryption: Not Remotely the Same

Base64 is not security. It has no key, no secret, and no protection.

Encoding is a public transformation. Everyone knows the rules, so everyone can reverse it — instantly, in a browser, with no password.

Encryption uses a key. Without that key the data is unreadable, and that is the entire difference.

We still find API keys "hidden" in config files as Base64. It fools a casual glance and nothing else. If it needs to stay secret, use our text encryption tool instead.

The one nuance worth granting: Base64 does stop credentials being scraped by the crudest automated log-grep. That is a very thin benefit to build a policy on.

Base64 Use Cases You Meet Every Day

Anywhere binary data has to survive a text-only channel. Five you have almost certainly used:

Email attachments. Every attachment since the 1990s travels this way, because SMTP was built for plain text.
Data URIs. Images embedded in HTML and CSS instead of being fetched separately.
JSON APIs. Files inside a payload that cannot hold binary.
Basic authentication. HTTP encodes "user:password" as Base64 — encoded, not protected, which is exactly why it needs HTTPS.
Certificates and keys. A PEM file is Base64 with header lines wrapped around it.

That last one catches people out. Because PEM is already Base64, encoding it again just doubles the size for no benefit.

Working with files rather than text? The file to Base64 encoder handles any type, and the Base64 to file decoder reverses it.

The Costs Worth Knowing

Three, and only the first gets mentioned often:

33% larger. Fixed by the maths, and gzip recovers less than you hope on already-compressed data.
Memory pressure. Encoding holds the original plus a bigger string at the same time.
Lost cacheability. Inline an image and the browser can no longer cache it separately.

That third one is the expensive one for websites. We go through the trade-off in when Base64 images are worth it.

Wrapping Up

Base64 encoding is a translation layer, not a lock. Three bytes become four text characters, the data stays identical, and anyone can reverse it.

Use it when binary has to cross a text-only boundary. Do not use it to hide anything, and watch the size before inlining it into a page.

Next steps: encoding and decoding Base64 in code, or what a data URI actually is.