Last updated 3 September 2026
When inlining an image is worth it
Base64 encoding turns binary data into text so it can live inside a stylesheet, an HTML attribute or a JSON payload. The cost is fixed and unavoidable: four characters for every three bytes, so about a 33% size increase before any compression. What you buy is the removal of a separate network request, which used to matter enormously and matters less now that HTTP/2 makes parallel requests cheap. The practical line sits somewhere under a few kilobytes — small icons, a tiny placeholder, an SVG that would otherwise be one more round trip. Above that the maths turns against you, and a photograph inlined into CSS is actively harmful because it cannot be cached separately, cannot be lazy-loaded, and blocks the stylesheet that carries it.
Related guide: How to optimise images for a faster website
When inlining an image is worth it
Converting an image to a Base64 data URI embeds it directly in your HTML or CSS, which removes one HTTP request. That used to be a meaningful optimisation. Under HTTP/2 and HTTP/3, where many files download in parallel over a single connection, the saving is much smaller than it was — and the cost has not changed.
That cost is real. Base64 encoding inflates the data by roughly 33%, and an inlined image cannot be cached independently. A logo referenced as a file is downloaded once and reused on every page; the same logo inlined into each page's CSS is re-downloaded with every page and re-parsed every time. For anything appearing site-wide, a normal file reference is almost always faster overall.
Where it genuinely helps
Small, single-use graphics are the sensible case: an icon a few hundred bytes in size, a background pattern, a placeholder that must appear before anything else loads. Inlining a tiny critical image in the initial HTML means it renders without waiting for a second round trip, which can visibly improve how quickly a page appears complete.
The other strong case is portability. A data URI travels with the document, so a single self-contained HTML file, an email template or an SVG with a small embedded raster will display without any external assets. As a rough guide, inlining is usually reasonable under about 5 KB and rarely worth it above 10 KB — and SVG, being text already, is normally better inlined as plain markup than converted to Base64 first.
Common questions
Why does the file get bigger?
Base64 represents three bytes as four printable characters, so encoded data is about a third larger than the original. That overhead is unavoidable — it is the cost of making binary data safe to embed in text.
When should I inline an image?
For small assets, roughly under a few kilobytes — icons, tiny placeholders, small SVGs. Above that the size penalty outweighs the saved request, and inlined images cannot be cached separately or lazy-loaded.
Does it work with SVG?
Yes, and SVG is often the best candidate because the files are small and the saved request matters proportionally more. For SVG you can also embed the markup directly, which avoids the Base64 overhead entirely.
Is my image uploaded?
No. The encoding happens in your browser and the result never leaves your device.
Does inlining an image make my site faster?
Sometimes, but less often than it used to. HTTP/2 and HTTP/3 download many files in parallel, so removing one request saves little, while the 33% size increase and loss of independent caching remain. For images used across multiple pages, a normal file reference is usually faster.
How large can an image be before inlining stops making sense?
As a rough guide, under about 5 KB is usually reasonable and above 10 KB rarely is. Beyond that, the encoding overhead and the inability to cache the image separately outweigh the saved request.
Should I convert SVG files to Base64?
Usually not. SVG is already text, so it can be pasted directly into HTML or CSS as markup. Doing that keeps it smaller than the Base64 version and leaves it styleable with CSS, which encoding would prevent.