Base64 Data URIs for Images: the +33% Overhead and When Inlining Wins

The +33% overhead, precisely

Base64 encodes 3 bytes into 4 ASCII characters, so encoded size grows by a factor of 4/3 - about 33% - plus a couple of padding characters. A 12 KB icon becomes roughly a 16 KB string; a 150 KB photo becomes about 200 KB of text. That growth is why you never base64 a large image and expect it to behave like the file.

A data URI embeds that string directly in HTML or CSS, e.g. <img src="data:image/png;base64,...">, so the browser gets the pixels without a second request - the single genuine benefit, and the reason it is limited to tiny assets.

The request saving is smaller on HTTP/2

On old HTTP/1.1 with a handful of parallel connections, killing one request for a small icon was a real win. On HTTP/2 (and HTTP/3) many resources share one multiplexed connection, so the per-request cost that data URIs dodge is much lower - which means the 33% size penalty now looks worse, not better.

There is a subtler cache cost too: a data URI inside your CSS or HTML is re-sent whenever that document or stylesheet changes, because it is not a separately cacheable file. A standalone image, cached by URL and content-hashed, is re-fetched far less often. Inline a sprite you change rarely; think twice before inlining anything a returning visitor already has cached.

What to inline, and what never to

Data URIs earn their overhead for very small, request-sensitive, above-the-fold assets: a critical icon, a tiny logo, a background texture needed before first paint. The threshold is genuinely small - tens of bytes to a few kilobytes, not hundreds.

For vector shapes, inline the SVG markup itself rather than a base64 PNG - it stays human-editable, gzips well, and scales - while the color picker helps you pull exact hex values into it.

Building and checking a data URI

Compress the image first with the compressor, then paste or load it in the encoder to get the string, and confirm the decoded round-trip matches. Read the encoded length before you ship it: if a tiny icon base64s to tens of kilobytes, you have inlined something too big and should serve it as a file instead.

To see the damage in a real page, run the HTML through the HTML beautifier and search for data:image - a large document full of base64 blobs is a classic sign of over-inlining, and the readable output makes the offenders obvious.

All of this happens locally on your machine, so an unreleased asset or a private image never leaves your device while you test the encoding.