Image to Base64 Converter
Encodes an image to a data URI in your browser, with the size it adds, the snippets it goes into, and a straight answer on whether inlining it is worth it.
This tool needs JavaScript: the encoding happens in your browser, which is also why nothing is uploaded.
The HTML snippet leaves alt empty on purpose: an empty alt is correct for decoration and wrong for anything else, and only you know which this is.
Base64 turns three bytes into four characters. That is the whole basis of every decision about data URIs: an
inlined image is a third larger than the file it replaces, before the data:image/png;base64, prefix.
Which makes the trade easy to state. A 400 byte icon becomes 536 characters and saves a request, and that is usually worth it. A 200KB photo becomes 267KB of stylesheet that cannot be cached separately, cannot be lazy-loaded, cannot be served as WebP to browsers that support it, and delays the render of everything after it. That is not.
So the tool encodes the file, reports what the encoding cost, and gives a straight answer about whether inlining it is a good idea.
How to use
- Drop an image in, or choose one. It is read in your browser; nothing is uploaded.
- Read the size line and the verdict. Under about 4KB, inlining usually wins.
- Copy the data URI, or copy the snippet for wherever it is going: CSS, HTML, Markdown or JavaScript.
Example
A 400 byte PNG icon:
400 B becomes 573 B of text, 43% larger
Worth inlining: under a kilobyte, where saving a request is worth more than the bytes base64 addsbackground-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUg…");The same tool on a 200KB photograph says the opposite, and says why: it can no longer be cached, lazy-loaded or served in a modern format separately.
Pitfalls
A third larger, every time. Plus the prefix. Gzip recovers some of it for text-heavy formats and almost none for an already-compressed PNG or JPEG.
An inlined image cannot be cached on its own. It is part of the stylesheet or the HTML, so it is re-downloaded whenever that changes, and it is downloaded even by pages that never display it.
It cannot be lazy-loaded or made responsive. No loading="lazy", no srcset, no modern format for
browsers that support one. Those are the features you are trading away.
HTTP/2 removed most of the reason to inline. Requests are cheap when they are multiplexed over one connection. The remaining case is a tiny asset needed for first paint.
An SVG does not need base64. It is text, so URL-encoding it produces a smaller data URI that is also readable in a diff. Pasting the SVG straight into the markup is usually better than either.
Content Security Policy may block it. A strict img-src or style-src without data: will refuse data
URIs, which is a deliberate choice on many sites.
The alt attribute is left empty on purpose. An empty alt is correct for decoration and wrong for anything else, and only you know which this image is.
Compatibility
The file is read with FileReader in your browser. Nothing is uploaded, nothing is stored, and the tool
works offline once the page has loaded.
Data URIs are supported in every browser in use, in CSS, HTML, and as an image source. Very old versions of Internet Explorer had a 32KB limit, which is one more reason the sensible ceiling is far below that anyway.
The size arithmetic is a pure module tested against the definition of base64 rather than against itself: four characters per three bytes, rounded up to a multiple of four, which is where the padding comes from. The verdict boundaries are tested at the points where the advice changes.
The file limit here is 8MB, which is already 11MB of text. Past that a data URI is longer than anything that sensibly pastes, and a file that size should not be inlined at all.