Image to Base64 Data URL
A data URL embeds an image directly into HTML, CSS, or JSON as text, removing the need for a separate HTTP request. It is a genuine optimisation for very small assets and a genuine mistake for large ones. The threshold is lower than most people assume.
How to use it
- Drop in a PNG, JPG, GIF, WebP, BMP, or SVG.
- The file is read and encoded to a data URL in the page.
- Download the text file containing the complete data URL.
When inlining is worth it
Every separate image is an HTTP request, and each request carries connection overhead, headers, and latency. For a very small asset, that overhead can exceed the size of the image itself, which is when inlining wins.
The practical threshold sits somewhere around 1 to 2 KB. Below that, inlining a tiny icon, a spacer, or a single-colour texture is usually a net gain. Above it the arithmetic reverses quickly, because the 33 percent Base64 penalty applies to the whole file and it is now embedded in a document that may not be cached as aggressively as an image would be.
HTTP/2 and HTTP/3 weakened the argument further by multiplexing many requests over one connection, which removed most of the per-request penalty that made inlining attractive in the first place.
The caching problem
This is the cost people forget. A separate image file is cached by the browser independently and reused across every page that references it. An inlined data URL is part of the document, so it is re-downloaded every single time that document is fetched, and it cannot be shared between pages.
Inline a 30 KB logo into a stylesheet and every visitor downloads it again on every cold load of that stylesheet, instead of once ever. For anything appearing on more than one page, a separate cacheable file is almost always faster in aggregate.
Where data URLs are genuinely the right tool
Embedding an image inside an SVG that will be rasterized, where external references are blocked outright, is a case with no alternative. The same applies to email templates, where many clients refuse to load remote images until the recipient clicks a warning, and to single-file HTML documents intended to work offline.
They are also useful for images that exist only transiently in the browser, such as a preview of a file the user just selected, where there is no server-side asset to link to at all.
For SVG specifically, consider whether you need Base64 at all. SVG is text, so it can be URL-encoded rather than Base64-encoded, which avoids the 33 percent penalty entirely and often produces a shorter string.
At a glance
| Accepted input | .png, .jpg, .jpeg, .gif, .webp, .bmp, .svg |
|---|---|
| Output | Complete data URL including the MIME prefix |
| Size change | Roughly plus 33 percent |
| Suggested ceiling | Around 1 to 2 KB per asset |
Frequently asked questions
How large an image is too large to inline?
Past 1 to 2 KB the overhead usually outweighs the saved request, and past that the lost caching makes it clearly worse. Large images should stay as separate files.
Does the output include the data: prefix?
Yes. The full data URL is produced with the correct MIME type, so it can be pasted straight into an img src or a CSS url().
Why is inlining bad for caching?
The image becomes part of the document rather than a separate cacheable resource. It is re-downloaded with every fetch of that document and cannot be shared across pages.
Is Base64 the best way to inline an SVG?
Usually not. SVG is text, so URL-encoding it avoids the 33 percent Base64 penalty and typically yields a shorter string.
Read more
Choosing an image format — Why the same photograph can be 40 KB or 4 MB depending on a single dropdown, and how to choose deliberately.