Base64 Data URIs: Does the 33 % Overhead Survive Compression?

Small images are sometimes embedded directly in HTML or CSS as Base64 data URIs, to save a separate request. Base64 is known to make data a third larger. But HTML and CSS are normally sent compressed. Does the 33 % overhead survive gzip and Brotli, and does it depend on the kind of image? We encoded twelve images of four kinds and compared every combination.

The test

The images were three small SVG icons (358 to 608 bytes) and three PNG icons (1 to 14 KB) generated by code, four 320-pixel JPEG thumbnails (MozJPEG quality 75, 7.5 to 11.3 KB) and two 1200-pixel JPEG photos (65 and 96 KB) from our CC0 corpus. For each image we measured the binary file, its Base64 text and a full CSS data URI, each after gzip (level 9) and Brotli (quality 11), the way a server would send them inside a page or stylesheet. For SVG we also measured the alternative of embedding the SVG as URL-encoded UTF-8 text instead of Base64. Calculations were done with Node.js 24. See our methodology.

Results

Uncompressed, Base64 always added a third. Every image grew by 33.3–34.1 %, as the encoding’s four-characters-for-three-bytes rule predicts.

For PNG and JPEG, compression removed almost all of it. After Brotli, the Base64 version of a JPEG thumbnail was only 0.6 % larger than the compressed binary file at the median, and the PNG icons 0.7 %; for the 1200-pixel photos the difference was practically zero. These formats are already compressed, so their bytes look random, and Brotli can turn Base64’s restricted alphabet back into nearly the original size.

For SVG, Base64 made things much worse. SVG is text that compresses very well on its own. Encoding it as Base64 scrambled the repetition that Brotli relies on: after compression, the Base64 SVG icons were about 70 % larger than the compressed SVG files (median of the three). Embedding the same SVG as URL-encoded text kept the penalty to 15–26 %.

Bytes are not the only cost

• No separate caching. An embedded image is downloaded again with every page or stylesheet that contains it, while a separate file is cached once.
• It delays what it is embedded in. A large data URI makes the HTML or CSS bigger, and CSS blocks rendering until it has arrived. Embedding a 96 KB photo in a stylesheet holds up the whole page.
• No savings from lazy loading. An embedded image arrives with the page whether or not it is ever shown, so loading="lazy" cannot save its bytes.
• Requests are cheaper than they were. Over HTTP/2, many small requests share one connection, which removes much of the original reason to embed.

When embedding makes sense

• Tiny images needed for the first paint, such as a placeholder for a large photo. Our placeholder test measured how small those can be.
• Small SVG icons in CSS, written as UTF-8 data URIs, never as Base64.
• Not for photos or anything over a few kilobytes. The byte overhead disappears with compression, but the loss of caching and the delay to rendering do not.

Practical conclusion

Base64’s 33 % overhead largely vanished after Brotli for PNG and JPEG (under 1 %), but SVG icons grew by about 70 % after compression. Embed only tiny images that are needed immediately, and embed SVG as text rather than Base64.

Limitations

Twelve images, maximum compression levels and byte counts only; we did not measure parsing or decoding time for embedded images. Servers compressing on the fly with lower levels will leave a slightly larger overhead.

Data and files

Download base64-overhead.csv (12 rows, 1.1 KB) · Method: testing methodology. Photos: image credits.