What Base64 actually does
Base64 maps every 3 bytes of input onto 4 printable characters (A–Z, a–z, 0–9, +, /), so arbitrary binary can travel through systems that only handle text — email bodies, JSON fields, data URLs, XML. It is an encoding, not encryption: there is no key, and every Base64 string is trivially decodable by anyone. It also inflates data by ~33% (plus occasional newlines), and it is not compression — encoded data is bigger than the original.
How the mapping works
The encoder treats input as a bit stream, re-slices it into 6-bit groups (26 = 64 values → one character each), and pads the final group with = when the input length isn't a multiple of three. That's why Base64 strings so often end in one or two = — and why a valid Base64 length is always a multiple of 4.
The variants you'll meet
| Variant | Alphabet difference | Where |
|---|---|---|
| Standard | + / | MIME, most defaults |
| Base64URL | - _, padding often dropped | JWTs, URLs, filenames |
| Base64 with newlines | 76-char lines | PEM certificates/keys |
Mixing variants is a classic integration bug: a JWT pasted with + becomes a space in a URL; a PEM parsed without stripping newlines fails. When a decoder errors, check padding and the alphabet before assuming the data is corrupt.
Legitimate uses — and the anti-pattern
- Good: embedding small images as data URLs (weigh against a separate cached file — Base64 in CSS re-downloads with every stylesheet change), passing binary payloads through JSON, email attachments.
- Bad: "hiding" API keys or secrets. Scanners decode Base64 on sight; treat anything Base64'd in source control as plaintext. Also avoid Base64-ing large assets inline — it blocks rendering and defeats HTTP caching.
Decode and encode any Base64, including file support, in the Base64 tools — client-side only.