← All guides

Base64: why binary data walks around dressed as text

What Base64 actually does, why it makes files 33% bigger, and the security mistake people keep making with it.

5 min read · Reviewed July 2026

Ad space (header)

Large parts of the internet's plumbing were built to carry text, not arbitrary bytes. Email, JSON, URLs, XML — all of them get confused or corrupt data when raw binary shows up. Base64 is the workaround: it re-spells any sequence of bytes using 64 safe characters (A-Z, a-z, 0-9, + and /), so binary can travel through text-only channels unharmed.

The mechanics are simple: take 3 bytes (24 bits), slice them into four 6-bit groups, map each group to one of the 64 characters. Three bytes in, four characters out — which is why Base64 output is always about 33% larger than the input. The = signs at the end are just padding when the input length isn't divisible by three.

Where you meet it daily

Email attachments are Base64 under the hood — that's how a photo rides inside a text-based mail protocol. Images embedded directly in CSS or HTML (data: URLs) are Base64. The middle chunk of every JWT auth token is Base64-encoded JSON — paste one into the decoder above and look. API keys, webhook payload signatures, basic-auth headers: Base64 everywhere.

The mistake: Base64 is not encryption

Base64 looks scrambled, and that fools people into using it as protection. It is not. Decoding requires no key, no password, no effort — the tool above does it instantly, and so can anyone. Real systems have leaked credentials by 'hiding' them in Base64 config values. The rule: Base64 is an envelope, not a safe. If data is sensitive, encrypt it; Base64 only makes it portable.

One more gotcha worth knowing: naive Base64 code breaks on emoji and accented text because it assumes one byte per character. Our encoder handles UTF-8 correctly — try 'café 🚀' and round-trip it.

Written and maintained by the Encode / Decode Tools team. Reviewed July 2026.

Ad space (footer)