Image to Base64
Convert an image into a Base64 data URI you can paste into HTML, CSS or JavaScript — with a clear account of when that is a bad idea.
A third larger, and over a compressed connection almost none of it survives
Base64 costs four characters for every three bytes, which is a third more, always. That is the number people quote and it is not the number that reaches the browser. Here are eight real files from this site, encoded and then gzipped, measured against gzipping the original bytes.
| File | Bytes | Encoded | After gzip | Against the original file |
|---|---|---|---|---|
| favicon-16.png | 378 | +33.3% | +4.0% | +10.3% |
| favicon-32.png | 675 | +33.3% | +3.0% | +6.5% |
| favicon.ico | 2,073 | +33.3% | -0.6% | -3.2% |
| apple-touch-icon.png | 3,144 | +33.3% | +6.3% | -1.6% |
| icon-192.png | 3,395 | +33.4% | +6.3% | -3.9% |
| icon-512.png | 15,493 | +33.4% | +11.1% | -10.2% |
| og.png | 72,672 | +33.3% | +2.1% | -1.4% |
| favicon.svg | 250 | +34.4% | +30.2% | +3.6% |
The overhead does not vanish because the compressor is clever about base64. It vanishes because an image is already compressed, so there was nothing in it for gzip to find — and base64 of incompressible bytes is itself nearly incompressible, which puts both sides on the same footing. Across the 7 already-compressed files the residue runs from -0.6% to +11.1%.
The SVG is the counter-example and the useful one. It is text, it was 20% compressible to begin with, and base64 destroys the byte alignment a compressor needs in order to see repetition. Encode it and you keep +30.2% of the penalty for good. If you inline one thing on this list, do not make it the SVG.
Several come out smaller than the file they encode
Which reads like a mistake and is not. Gzipping a base64-encoded PNG can produce fewer bytes than the PNG itself, because PNG compresses within each row of pixels and leaves structure that a general-purpose compressor can still take out.
5 of the 8 files above end up smaller as a gzipped data URI than as the original binary: favicon.ico, apple-touch-icon.png, icon-192.png, icon-512.png, og.png.
So on a compressed connection an inlined image is not the extravagance the character count suggests. It has other costs — it cannot be cached on its own, and it delays whatever it is embedded in — but transfer size is not one of them.
The small ones go the other way, which is the opposite of the usual advice
"Inline the small ones" is the received wisdom, and the small ones are the ones that cost you. Below about a kilobyte there is not enough redundancy to pay for gzip's own fixed overhead.
| File | Bytes | gzip alone | As a gzipped data URI |
|---|---|---|---|
| favicon-16.png | 378 | 401 (bigger) | +10.3% |
| favicon-32.png | 675 | 698 (bigger) | +6.5% |
| favicon.svg | 250 | 199 | +3.6% |
A 378-byte icon gzips to more than 378 bytes all on its own, before any encoding — there is simply nothing in it to compress. The threshold where the arithmetic turns is around 1,024 bytes on this sample.
The data:image/png;base64, in front adds a fixed
22 characters, which matters to nothing except the
very smallest files — and those were already the losing case.
How to use
- Choose your image.
- Copy the data URI or the ready-made tag.
- Use it only for small images.
- Prefer a normal image file for anything substantial.
Frequently asked questions
When is a data URI a good idea?
For very small images — an icon, a tiny background pattern, a spacer — where the saved network request outweighs the size penalty. It is also useful for self-contained documents and emails that must carry their images with them.
Why does it make the file bigger?
Because Base64 represents three bytes using four characters, adding about 33 per cent. That penalty applies to every page load, and unlike a separate image file the embedded data cannot be cached independently — so a shared image embedded in five pages is downloaded five times.
What is the main downside for a website?
Losing caching and parallelism. A normal image is fetched separately, cached by the browser, and downloaded alongside other resources. Embedded data has to be parsed as part of the document, which delays rendering — so a large data URI can make a page noticeably slower to display.
Is there a size limit?
No hard one, but practical limits arrive quickly. Above a few kilobytes the trade-off has usually gone the wrong way, and very large data URIs bloat the HTML or CSS file, slow parsing, and make the source unreadable. A few kilobytes is a reasonable ceiling.
Can I use this for SVG?
You can, though for SVG there are better options — inlining the markup directly keeps it stylable and often takes less space than Base64. If you do encode SVG as a data URI, URL-encoding it is generally smaller than Base64 because the content is text.
Does my image get uploaded?
No. The conversion happens in your browser and nothing is transmitted, which matters if the image is not something you would hand to a website.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.