Base64 Encoding Explained: When and Why to Use It

Base64 shows up everywhere — inside JWTs, email attachments, data URLs, API credentials, Kubernetes secrets, SSH keys. It's one of the most-used encodings on the internet, and also one of the most misunderstood. Half the bug reports that mention Base64 are really about one of two confusions: developers treating it as encryption (it isn't), or surprised that their "compressed" payload got 33% bigger (that's the whole point of the encoding). This guide walks through what Base64 actually is, how the bits get packed, where it genuinely helps, and the situations where you should reach for something else.

1. What Base64 actually is — and what it is NOT

Base64 is a binary-to-text encoding. Its only job is to take arbitrary bytes — a PNG file, a TLS certificate, a protobuf message — and rewrite them using a small set of characters that are safe to embed in text-based channels like email bodies, JSON fields, URLs, or HTTP headers. The alphabet is 64 characters long, which is where the name comes from.

The critical thing to understand up front: Base64 is not encryption. It has no key, no secret, no cryptographic guarantee of any kind. Anyone can decode a Base64 string in the browser console with a single call to atob(). Putting an API key through Base64 before committing it to a repo is exactly as safe as committing the raw key — you've just obscured it from casual glance. Real security comes from TLS in transit, proper secret managers at rest, and cryptographic algorithms like AES or ChaCha20 for confidentiality.

Think of Base64 the way you'd think of hexadecimal: a way to represent binary data in a text-friendly form. Hex uses 16 characters and doubles the size of the input; Base64 uses 64 characters and inflates by only ~33%. That's it. It's a plumbing detail, not a security layer.

2. How the encoding actually works

Base64 processes input 3 bytes at a time. Three bytes is 24 bits, and 24 bits split evenly into four 6-bit groups. Each 6-bit group becomes one character in the output — 2⁶ = 64, which is why the alphabet has exactly 64 entries. The standard alphabet defined in RFC 4648 is:

• A–Z for values 0–25
• a–z for values 26–51
• 0–9 for values 52–61
• + for value 62
• / for value 63

When the input length isn't a multiple of 3, the encoder pads the final group with zero bits and then appends = characters to signal the original length. One leftover byte produces two Base64 characters plus ==; two leftover bytes produce three Base64 characters plus =. The padding isn't data — it's a length marker that some decoders require and others tolerate missing.

Because you end up with 4 output characters per 3 input bytes, Base64 output is exactly 4/3 the size of the input — a 33.3% inflation, or 33.4%–34% once padding is factored in. A 300-byte payload becomes 400 characters. A 3 KB payload becomes 4 KB. There's no way to squeeze this: the math is the encoding.

3. Legitimate use cases

Base64 earns its keep in any situation where you have binary data that needs to travel through a text-only channel. The classic examples:

• Email attachments. SMTP is a 7-bit text protocol from 1982. RFC 2045 (MIME) specifies Base64 as the standard way to pack binary attachments — PDFs, images, ZIPs — into the body of an email so that intermediate mail servers don't corrupt the bytes.
• Data URLs for small inline assets. A data:image/png;base64,iVBOR... URL embeds an image directly into HTML or CSS. For very small, frequently-used icons or fonts this can save a round-trip request, though the trade-offs (no caching, 33% bloat) mean it only pays off below a few KB.
• JWT payload segments. JSON Web Tokens (RFC 7519) are three URL-safe Base64 segments joined by dots: header.payload.signature. The payload is a JSON object Base64-encoded so it can safely ride in an Authorization header or URL parameter.
• API tokens and credentials. Many services return bearer tokens, webhook secrets, and API keys as Base64 strings because they need to be safely copy-pasteable and embeddable in headers.
• HTTP Basic Auth. The Authorization: Basic <value> header carries the string username:password Base64-encoded. This is the textbook example of encoding-is-not-encryption — Basic Auth only provides confidentiality when it rides on top of TLS.

4. When NOT to use Base64

The mistakes tend to cluster around three patterns.

Don't use Base64 as security or obfuscation. If a value is sensitive — a password, an API key, a user's PII — Base64-encoding it before storage or transmission provides zero protection. It's trivially reversible in any language, browser, or editor. Use actual cryptography (TLS, AES-GCM, age) and a proper secret manager.

Don't inline large images as data URLs. It's tempting to embed a hero image or a logo directly into HTML or CSS with data:image/...;base64,... because it saves a request. For anything beyond a few KB this backfires: the 33% size bump is added to your HTML/CSS bundle, which blocks rendering more than a separate image would; the browser can't cache the image independently, so every page load re-downloads it; and you lose the ability to parallelise the image request with other assets. The rough rule of thumb is "only inline if under ~2–4 KB and used on most pages."

Don't use Base64 as a replacement for proper binary upload. If you're uploading a 50 MB video to your own backend, don't wrap it in JSON as a Base64 string — you've just turned a 50 MB upload into a 67 MB upload and forced the server to allocate a string that size before it can decode. Use multipart/form-data or a pre-signed S3 POST. Base64 in request bodies only makes sense when the protocol demands JSON (some webhook systems, some legacy SOAP endpoints) and the payload is small.

5. The URL-safe Base64 variant

Standard Base64 has two alphabet characters — + and / — that are problematic in URLs. + can be interpreted as a space by some URL decoders, and / is the path separator. The trailing = padding is also a reserved character in URL query strings.

RFC 4648 §5 defines a URL-safe Base64 variant that makes three changes:

• + is replaced with -
• / is replaced with _
• Trailing = padding is typically stripped entirely

This variant is what you see in JWTs, in OAuth 2.0 PKCE verifier strings, in many webhook signature formats, and in a lot of modern REST APIs. The encoding and decoding are byte-identical to standard Base64 — only the output character set changes. If you're building something that puts Base64 into a URL path, query string, cookie, or filename, use the URL-safe variant from the start. Retrofitting later is annoying because you need both encoder and decoder to agree.

6. Real-world overhead math

Because the inflation factor is exact, you can plan for it with arithmetic rather than benchmarks. Here's what the 33% overhead looks like at different input sizes:

The overhead is predictable: output bytes ≈ ⌈input / 3⌉ × 4. Whether that matters depends on context. For a 256-byte session token embedded in a header, 88 extra bytes is irrelevant. For a 1 MB PDF uploaded through a JSON API a hundred times a minute, the 33 GB of extra bandwidth per day is a real operational cost.

Frequently asked questions

References

• IETF RFC 4648 — The Base16, Base32, and Base64 Data Encodings
• IETF RFC 2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
• IETF RFC 7519 — JSON Web Token (JWT)
• MDN Web Docs — Data URLs (developer.mozilla.org/docs/Web/URI/Schemes/data)
• MDN Web Docs — Window.btoa() and Window.atob()