Base64 Explained: What It Is and When to Use It

The root problem is that not all bytes are safe to transmit in all contexts. A null byte (0x00) terminates strings in C. Bytes above 127 are interpreted differently across character encodings. SMTP servers historically rejected non-ASCII bytes. Line endings (\r\n vs \n) got mangled in transit.

Base64 sidesteps all of this by mapping every possible sequence of bytes to a fixed set of 64 characters: A–Z, a–z, 0–9, +, and /, plus = as a padding character. Every character in that set is printable, unambiguous in ASCII, and safe across virtually all text-handling systems built since the 1980s.

The name comes directly from the alphabet size. Base16 (hex) uses 16 symbols; Base32 uses 32; Base64 uses 64. A larger alphabet means more bits can be packed into each character, which is why Base64 is more space-efficient than hex (which doubles the byte count instead of adding 33%).

Base64 works by reading input 3 bytes (24 bits) at a time and splitting those 24 bits into four 6-bit groups. Each 6-bit value (0–63) maps to one character in the alphabet. If the input length is not divisible by 3, padding characters (=) are appended to round up to the nearest 4-character block.

A concrete example: encode the ASCII string Man.

1. M = 0x4D = 01001101, a = 0x61 = 01100001, n = 0x6E = 01101110
2. Combined: 010011 010110 000101 101110
3. Decimal: 19 22 5 46
4. Characters: T W F u → TWFu

No information is lost. Base64 is fully reversible — decode TWFu and you get Man back exactly.

Every 3 bytes of input become 4 bytes of Base64 output. That is a 4/3 ratio, or roughly 33% size increase. For a 1 MB image, expect about 1.37 MB of Base64 text.

This overhead is not a bug — it is an unavoidable consequence of the encoding math. But it is a cost worth tracking. Inline Base64 images in CSS or HTML skip an HTTP request, which can be a net win for small icons. For large assets, the 33% bloat plus the inability to cache the embedded resource independently usually makes a separate file URL the better choice.

Rule of thumb: inline Base64 makes sense for assets under roughly 5–10 KB. Above that, the cache and bandwidth costs compound faster than the saved round-trip pays back.

A data URI embeds file content directly inside a URL. The format is:

data:[<mediatype>][;base64],<data>

For a small PNG icon, a data URI looks like:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

Common uses include:

• CSS backgrounds: inline small icons or patterns to eliminate HTTP requests
• HTML email: embed images because many email clients block external URLs
• SVG fonts: bundle font files directly inside SVG documents for offline use
• JSON APIs: transmit binary file content (PDFs, images) inside a JSON field without multipart encoding

Browsers support data URIs for src and href attributes, CSS url(), and <img> tags. There is a practical size limit — very long data URIs can cause rendering delays and some older browsers cap them around 32 KB.

Standard Base64 uses + and / as the 62nd and 63rd characters. Both are special in URLs: + means a space in form-encoded data, and / is a path separator. Put standard Base64 in a URL query string and those characters corrupt the value.

Base64url solves this by replacing + with - and / with _. Padding (=) is also typically omitted since it can confuse query parsers. Everything else is identical.

You will encounter base64url in:

• JWTs (JSON Web Tokens) — the header, payload, and signature are all base64url-encoded, joined by dots
• OAuth 2.0 PKCE — the code challenge is a base64url-encoded SHA-256 hash
• URL-safe identifiers — random tokens embedded in links (password resets, email confirmations)

If you are decoding a JWT by hand and your Base64 decoder throws an error, the fix is almost always to swap - back to + and _ back to / before decoding, and to add padding if the string length is not a multiple of 4.

Base64 is not encryption. It is not a hash. It is not even a weak form of obfuscation for any practical purpose — every developer on earth recognizes a Base64 string on sight, and decoding it is one click. The encoded data is every bit as readable as the original, just in a different representation.

This distinction matters in real systems. Storing a password as Base64 in a database provides zero protection — an attacker who reads the database column simply decodes it. Sending credentials in an HTTP header as Authorization: Basic <base64> (HTTP Basic Auth) is only safe over TLS, because the credentials are trivially reversible. Never use Base64 as a substitute for hashing, signing, or encrypting sensitive data.