Image to Base64 Converter — Data URI Generator
Turn an image into a data URI ready to paste into CSS, HTML or JSON.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
Convert an image to a Base64 data URI, with output ready to paste as a CSS background, an HTML <img> tag, or a raw string for JSON.
The tool shows the encoding overhead and warns when a file is large enough that inlining it will hurt more than it helps.
How to use Image to Base64
- Drop in your image.
- Pick an output format — data URI, CSS, HTML or raw Base64.
- Copy or download the result.
When inlining an image is worth it
A data URI removes one HTTP request, which used to matter a great deal. Under HTTP/2 and HTTP/3, requests are multiplexed over a single connection and are far cheaper — so the calculus has shifted.
Inlining still makes sense for very small assets: icons, a 1×1 spacer, a small repeating texture, or an image that must be present before first paint. Below roughly 8 KB the saved request generally wins.
Why big images should not be inlined
Base64 makes data about 33% larger, since every 3 bytes become 4 characters. Worse, an inlined image cannot be cached separately — it is re-downloaded with the HTML or CSS on every page load, and it blocks rendering of that file while it downloads. A 200 KB photo inlined into your stylesheet delays every page on the site.
SVG is usually the better inline choice
If your asset is an icon, inline the SVG markup directly rather than Base64-encoding it. SVG is already text, so there is no 33% penalty, it compresses well with gzip, and you can restyle it with CSS — including changing its colour on hover, which is impossible with a data URI.
Frequently asked questions
When should I inline an image as Base64?
Only for small assets — roughly under 8 KB. Icons, tiny textures, or images needed before first paint. Above that, the 33% size penalty and loss of separate caching outweigh the saved request.
Why is the Base64 version bigger than my file?
Base64 encodes every 3 bytes as 4 characters, so output is about 33% larger. That is inherent to the encoding, not a flaw in the tool.
Is inlining images good or bad for page speed?
It depends on size. Under HTTP/2 requests are cheap, so the old argument for inlining is much weaker. Large inlined images actively hurt: they cannot be cached separately and are re-downloaded with the HTML or CSS every time.
What about SVG icons?
Inline the SVG markup directly rather than Base64-encoding it. SVG is already text, so there is no size penalty, it gzips well, and you can restyle it with CSS — impossible with a data URI.