Base64 explained, and when you actually need it

Base64 is one of the most-encountered, least-understood encodings on the web. Strings that start with ey... (JWTs), strings that start with data:image/png;base64, (data URLs), strings in HTTP Authorization: Basic headers — all Base64. The Base64 tool lets you encode and decode them on demand.

What Base64 actually does

Base64 takes any sequence of bytes and represents it using only 64 printable ASCII characters: A-Z, a-z, 0-9, +, and / (plus = for padding).

The math: every 3 bytes (24 bits) of input become 4 characters (24 bits worth of "base 64" digits) of output. So:

• Output is 33% larger than input.
• Every output character is safe to put in URLs, JSON, email headers, and pretty much any text channel.
• It's reversible. No information is lost.

Base64 is not encryption. Anyone who sees aGVsbG8= can decode it to hello in a fraction of a second. Don't use Base64 to "hide" data — that's not what it does.

Base64 is not compression. It actually makes the data bigger, not smaller.

The five real use cases

1. Sending binary in text-only channels. Email (especially old SMTP), HTTP headers, JSON strings — these can carry text safely but mangle raw binary. Base64 is the universal "wrap binary in safe ASCII" protocol.

2. Data URLs. data:image/png;base64,iVBORw0KGgo... embeds a small image directly in HTML or CSS. Useful for tiny icons or transparent placeholders. Past about 1 KB the size penalty (33% inflation, no caching) outweighs the savings of one fewer HTTP request.

3. HTTP Basic Auth. The Authorization: Basic dXNlcjpwYXNzd29yZA== header is username:password encoded with Base64. Anyone who sees it can decode the password. This is why Basic Auth must always travel over HTTPS.

4. JWT payloads. A JWT has three Base64 parts: header, payload, signature. The JWT Decoder parses them out. Like Basic Auth, JWT payloads are readable — they're not secret. The signature is what proves authenticity.

5. Inline cryptographic material. SSH keys, TLS certificates, signing keys — almost all crypto material that travels in text is Base64-encoded. The framing (-----BEGIN PRIVATE KEY-----) is plain text; the bytes between are Base64.

URL-safe Base64

Standard Base64 uses + and / which need URL-encoding when embedded in URLs. URL-safe Base64 swaps those for - and _ (and often drops the = padding). Most JWT implementations use URL-safe.

The tool here accepts both flavors when decoding. When encoding, you'll get standard Base64 — paste it into a URL only if your decoder accepts standard form (most do).

When you don't want Base64

• For long binary blobs. A 10 MB image as Base64 is 13.3 MB and unreadable. Use binary upload (multipart/form-data) or signed URLs instead.
• As a "lite encryption." It's not. Anyone can decode it.
• For URL parameters that need to be human-readable. Pick a slug-friendly encoding instead.

For everything else — embed in JSON, pass through headers, fit into a JWT — Base64 is the right tool.