What Base64 Inlining Does to Page Speed
Base64-inlining an image embeds the binary data directly into your HTML or CSS as a data URI. The browser does not make a separate HTTP request for that image — but the document itself grows by ~33% the size of the original binary. For a 50KB image, that adds ~67KB to your initial HTML. For modern HTTP/2 and HTTP/3 connections, the savings of one fewer request are often less than the cost of the inflated document.
When Base64 Inlining Helps
Tiny icons under ~2 KB are good candidates: SVGs and small PNG sprites benefit from being inlined because the cost of an HTTP request (DNS, TLS, headers) outweighs the document inflation. Critical above-the-fold images that block first paint can also benefit because they avoid blocking the first render on a network round trip.
When Base64 Inlining Hurts
Anything above ~4 KB inflates HTML/CSS so much that compression cannot recover the cost. Images that change frequently lose the benefit of HTTP caching when inlined. Images shown only on certain pages or interactions add weight to every request that loads the file. And any image larger than 10 KB is almost always better as a separate file with proper caching headers.
Practical Thresholds
A common rule of thumb: inline if the image is under 2 KB and used on more than half of page loads. Otherwise serve as a separate file with HTTP/2 server push, preload hints, or a <picture> element with WebP/AVIF fallbacks.
Benchmark Numbers
On a 4G connection with 50ms RTT, the break-even point is around 1.5 KB: below that, inlining wins; above, the inflated HTML costs more than a parallel request. On 3G or high-latency networks the threshold rises to about 4 KB. On HTTP/3 with 0-RTT, separate requests are nearly free, so inline only the truly tiny.
Try It Yourself
Use our companion tool to apply what you read above.