Last updated 28 August 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.
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.