Base64 Encoding Explained (and When to Reach for It)
· 5 min read
Base64 shows up in HTTP Basic Auth, JWT payloads, data: URLs, and email attachments. It's not encryption — it's a way to package arbitrary bytes into characters that survive transport channels that only accept printable text.
What it does
Base64 takes three bytes of input (24 bits) and packs them into four 6-bit characters from a 64-character alphabet: A-Z, a-z, 0-9, plus "+" and "/". When the input length isn't a multiple of 3, the output is padded with "=".
That mapping is why Base64 output is ~33% larger than the input.
When to use it
- HTTP Basic Auth headers. The "Authorization: Basic ..." value is "user:password" run through Base64.
- Inline data: URLs. A small SVG icon Base64-encoded in CSS removes an HTTP request.
- JWT payloads. The header and payload of a JWT are Base64url-encoded JSON.
- Storing binary in JSON. If you need to ship a binary blob inside a JSON field, Base64 is the lingua franca.
Encode a value yourself with our Base64 Encoder — it runs locally.
When NOT to use it
- Encryption. Base64 is not a secret; anyone can decode it. If confidentiality matters, encrypt first, then Base64.
- Compression. Base64 increases size. If size matters, gzip first.
- As an ID. Random IDs should be UUIDs or short alphanumeric — Base64 is awkward to type and copy because of "+" and "/".
Three common gotchas
1. URL-safe variants. Standard Base64 uses "+" and "/", which are not URL-safe. The "base64url" variant substitutes "-" and "_" and strips padding. JWT uses base64url. Mixing the two produces "invalid padding" errors.
2. UTF-8 vs Latin-1. Encoding "café" with Latin-1 gives a different output than UTF-8. When in doubt, encode UTF-8.
3. Line wrapping. Some legacy tools wrap Base64 at 76 characters with newlines. Most modern parsers tolerate that, but if yours doesn't, strip whitespace first.
Decoding works the same way in reverse — see Base64 Decoder.