Base64 & Data URLs: When to Inline Binary Content

Base64 is one of those technologies that's been around for so long, most developers take it for granted without really understanding it. Data URLs build on Base64 to embed entire files into HTML, CSS, and JSON. Both are powerful — and both are misused regularly.

Why does Base64 exist?

Many transport channels — email headers (RFC 822), URLs, JSON strings, HTTP Basic auth — only support a limited set of printable ASCII characters. But computers store data as bytes (0–255), most of which aren't printable. Base64 bridges the gap by mapping every 3 bytes of binary into 4 characters from a 64-character alphabet (A-Z a-z 0-9 + /).

The output is always ASCII, always safe to paste into emails or JSON, and always reversible. The cost is a ~33% size increase — perfectly acceptable for the small payloads where Base64 shines.

Where Base64 actually appears

• Email attachments: MIME wraps binary in Base64 for transport.
• HTTP Basic auth: Authorization: Basic dXNlcjpwYXNz is just user:pass in Base64.
• JSON Web Tokens (JWT): three Base64-encoded segments separated by dots.
• Data URLs: embedding images and fonts directly in HTML/CSS.
• Storage in JSON: binary data (file uploads, images) sent as Base64 strings.

Standard vs URL-safe Base64

The standard alphabet uses + and / — both have special meaning in URLs. URL-safe Base64 swaps them for - and _, and drops the trailing = padding (since some URL grammars don't allow it).

When you see a JWT, the - and _ in the encoded segments are URL-safe Base64. When you see Base64 in an email, with + and /, that's standard Base64.

Data URLs: inlining files

A data URL is a way to embed a file inline, using Base64 (or sometimes percent-encoding for text):

The browser treats this as if it had downloaded a real file with the given MIME type. You can use data URLs as img src, CSS background-image, even iframe src.

When data URLs help

• Tiny icons (a few hundred bytes) where the cost of a separate HTTP request exceeds the size penalty.
• Generating images dynamically client-side for download or display.
• Email templates where external images would be blocked or stripped.

When data URLs hurt

• Large images — the 33% size penalty multiplies, and you lose browser caching.
• Anything that should be reused across pages — separate files cache; inlined files re-download every page.
• Performance-critical pages — large data URLs in CSS block rendering.

Common Base64 misuses

• Storing it as “encryption”: Base64 is encoding, not encryption. Anyone can decode it instantly.
• Base64-encoding URLs: URLs are already ASCII. There's no reason to Base64-encode them. (URL encoding for unsafe characters is different — that's percent encoding.)
• Base64-encoding entire files for upload: a multipart/form-data request sends binary directly with no encoding overhead. Only Base64 if your transport channel demands it.