What Base64 Actually Is (And What It Isn't)

The one-sentence version

Base64 rewrites data using only 64 characters that survive being treated as text, so it can travel through places that would otherwise corrupt it.

That's the whole idea. Everything else is detail.

The problem it solves

Plenty of systems were built assuming they'd only ever carry readable text. Email headers, JSON strings, URLs, XML attributes, config files. Hand them raw bytes — an image, a compressed archive, a cryptographic key — and something in the chain will mangle it. A byte that happens to look like a newline gets treated as a newline. A byte above 127 gets re-interpreted by whatever encoding the next system assumes.

Base64 sidesteps all of that by using a deliberately boring alphabet: A-Z, a-z, 0-9, + and /. Sixty-four characters, every one of them safe nearly everywhere.

U0dWc2JHOHNJSGR2Y214a0lRPT0=

Hello, world!

U0dWc2JHOHNJSGR2Y214a0lRPT0

How the conversion works

The trick is that 64 is a power of two. One Base64 character carries exactly 6 bits, because 2⁶ = 64.

Your data arrives as bytes, which are 8 bits each. So Base64 regroups the bits:

• Take 3 bytes — that's 24 bits
• Split those 24 bits into 4 groups of 6
• Look each group up in the 64-character alphabet

Three bytes in, four characters out. Every time.

That is where the 33% size increase comes from. You're spending 4 characters to carry what used to take 3, and 4 ÷ 3 is about 1.33. It isn't overhead you can tune away — it's arithmetic.

Those = signs on the end

Base64 works in blocks of 3 bytes, and real data rarely divides evenly into 3.

When the last block is short, the encoder pads the output with = so the length always comes out as a multiple of 4:

• 3 bytes left over → no padding
• 2 bytes left over → one =
• 1 byte left over → two =

The padding carries no data. It just tells a decoder how much of the final block was real.

Base64 is not encryption

This is the mistake worth being loud about.

Base64 is a public, reversible transformation with no key. Anyone can decode it instantly — the tool above does it without being asked. If you Base64 a password, an API token or a customer record, you have not protected it. You have made it very slightly less obvious while leaving it completely readable to anyone who looks.

Encoding answers "can this data survive the journey?" Encryption answers "can anyone else read it?" They are different questions and Base64 only answers the first.

The URL-safe variant

Standard Base64 uses + and /, and both cause trouble in a URL: + is sometimes read as a space, and / is a path separator.

So there's a second alphabet, usually called base64url:

• + becomes -
• / becomes _
• padding = is usually dropped entirely

This is what JSON Web Tokens use. A JWT is three base64url sections separated by dots, which is why pasting one into a standard decoder often fails — the decoder hits a - or _, which aren't valid in its alphabet, and gives up. The tool above shows the URL-safe form alongside the standard one so you can see the difference.

Where you'll actually meet it

• Data URLs — data:image/png;base64,iVBOR... embeds a whole image inside an HTML or CSS file
• Email attachments — MIME has encoded attachments this way since the early nineties
• JSON Web Tokens — the header and payload are base64url, and readable by anyone holding the token
• HTTP Basic auth — Authorization: Basic is a Base64'd user:password, which is exactly why it needs HTTPS
• Config and secrets files — certificates and keys are often stored Base64'd so they fit on one line

Where people go wrong

• Treating it as security. It is not. It never was.
• Mixing the two alphabets. A base64url string fed to a standard decoder fails on - and _.
• Forgetting the padding. Strip = for a URL, then add it back before decoding, or a strict decoder rejects the input.
• Encoding things that didn't need it. Plain ASCII text usually travels fine on its own, and you've just made it a third bigger for nothing.
• Assuming an encoding. Base64 encodes bytes. If you're encoding text, the decoder has to agree on the character encoding — this tool uses UTF-8 both ways, which is the modern default.

The short version

Base64 makes data safe to move, not safe to share. Three bytes become four characters, the result is about a third bigger, = is padding, and -/_ mean you're looking at the URL-safe variant. If you need something to stay private, you need encryption — this isn't it.