Base64 Explained

The problem: text-only channels

Many systems were built to carry text: email (SMTP), URLs, JSON, HTML. Raw binary bytes can contain values these systems interpret as control characters, line endings or string terminators — a zero byte ends a C string, for instance. Send a photo's raw bytes through such a channel and it gets mangled. Base64 solves this by re-encoding arbitrary bytes using only 64 safe, printable ASCII characters.

How it works: 3 bytes → 4 characters

The name says it all: base 64 = 2⁶, so each output character carries exactly 6 bits. The encoder takes 3 input bytes (24 bits), splits them into four 6-bit groups, and maps each group to one character of the 64-character alphabet:

A worked example — encoding Hi:

1. To bytes: H = 72 = 01001000, i = 105 = 01101001
2. Regroup into 6-bit chunks: 010010 000110 1001 — only 16 bits, so pad with zeros to make three full groups: 010010 000110 100100
3. Map to alphabet: 18→S, 6→G, 36→k, giving SGk
4. Pad to 4 characters: the missing fourth group becomes =

Result: Hi → SGk=. The = is padding: it tells the decoder the input wasn't a multiple of 3 bytes, so it knows exactly where the real data ends. You'll see one = or two (==) at the end of Base64 strings.

The 33% overhead

Base64 isn't free: 3 bytes become 4 characters, so encoded data is about 33% larger than the original. That's the price of text-safety, and it's why you wouldn't Base64-encode a video file for storage — but for embedding a small icon directly in a stylesheet, the convenience wins.

Where you'll meet Base64

• Email attachments: MIME encodes every attachment in Base64 so 7-bit SMTP servers carry it safely.
• Data URIs: <img src="data:image/png;base64,iVBOR…"> embeds an image directly in HTML — no separate file request.
• APIs and JSON: binary blobs (keys, tokens, file contents) travel inside JSON as Base64 strings.
• Basic auth: the Authorization: Basic header is just username:password in Base64.

Base64 variants

The standard alphabet has one wart: + and / are special characters in URLs, and = padding can confuse query strings. So a URL-safe variant swaps them for - and _ (and usually drops the padding) — you'll see it in JWT tokens, which are three Base64url-encoded segments separated by dots. The encoding logic is identical; only the last two alphabet characters change. If you're ever debugging a token that won't decode, check which alphabet it uses first.

Base64 is not encryption

This is the critical misconception. Base64 is an encoding — a reversible format change, like writing a number in hexadecimal. Anyone can decode it instantly, with no key. It provides zero secrecy. If you see credentials or "obfuscated" data in Base64, treat them as plaintext. Real confidentiality needs actual encryption (like AES or TLS) before any encoding.

Key takeaways

• Base64 re-encodes binary data using 64 safe text characters (A–Z, a–z, 0–9, +, /).
• 3 bytes become 4 characters; = padding marks inputs that aren't a multiple of 3 bytes.
• It costs ~33% extra size — the price of surviving text-only channels.
• Common in email attachments, data URIs, JSON APIs and auth headers.
• Base64 is encoding, not encryption — it hides nothing.

Frequently asked questions