How to use
- Drop an image, or click to pick one.
- Read the size comparison — original, encoded, and the percentage increase.
- Choose an output format: plain data URI, raw Base64, CSS, HTML or Markdown.
- Switch to Base64 → Image to go the other way and download the result.
About inlining images
A data URI puts an image’s bytes directly inside your HTML or CSS instead of pointing at a
separate file. The appeal is obvious: one fewer network request, and no chance of a broken
link. The cost is less obvious, and it comes in two parts.
The first is arithmetic. Base64 encodes three bytes as four characters, so the data is always
about 33% larger than the file it came from. There is no way around this — it is what
makes the encoding safe to embed in text.
The second cost is the one that actually matters, and it is easy to miss: an inlined image
cannot be cached on its own. A normal image file is downloaded once and reused on every page
that references it, for as long as the cache allows. An inlined image is part of the document,
so it is re-downloaded with every page load, on every page — and because it sits in the HTML or
CSS, the browser cannot start rendering until it has all of it. A 50 KB inlined background can
delay first paint on every single page view, while the same file as a separate request would
have been fetched once and then never again.
There is also a historical footnote worth knowing. Much of the advice recommending data URIs
dates from the HTTP/1.1 era, when browsers allowed only about six parallel connections per
host and each request carried real queuing cost. Under HTTP/2 and HTTP/3, requests are
multiplexed over a single connection and that penalty is largely gone. The case for inlining is
considerably weaker than the advice you will find still repeated.
The remaining sound use is small and repeated: an icon of a few hundred bytes used across the
site, a tiny background pattern, an image needed before any other request completes. Below a
couple of kilobytes the saved round trip usually wins. Past ten or so, it usually does not.
Frequently asked questions
Why is the Base64 version bigger than my file?
Base64 represents three bytes using four characters, so the encoded data is always about 33% larger — that is arithmetic, not inefficiency. Add the data:image/png;base64, prefix and a small icon can grow by more than a third. This tool shows the exact figure because it is the number that decides whether inlining is worth it, and most converters do not display it.
When should I actually inline an image?
When it is small and appears on nearly every page — an icon, a tiny logo, a background pattern. Below roughly 2 KB the request you save usually outweighs the extra bytes. Past about 10 KB it rarely does. In between it depends on your page, and the honest answer is to measure rather than follow a rule.
Why should I not inline large images?
Two reasons that compound. The bytes grow by a third, and — more importantly — an inlined image cannot be cached separately. A normal image is downloaded once and reused across every page; an inlined one is re-downloaded with the HTML on every single load, and it blocks the page from rendering until it has arrived. HTTP/2 also made the old argument for inlining much weaker, since parallel requests no longer queue the way they did.
How is the image type detected?
From the file signature — the first few bytes — not the file name. This matters: rename a JPEG to .png and a name-based converter emits a data URI declaring image/png with JPEG content inside. Browsers usually render it anyway, but email clients, PDF generators and stricter image libraries do not, and the resulting bug is very hard to trace because the file looks fine.
Is my image uploaded?
No. The file is read with the browser's File API and encoded locally. This is worth knowing whenever the image is a screenshot of something internal, a design that has not shipped, or a document.
Can I convert a data URI back into a file?
Yes — switch to Base64 → Image, paste either a full data URI or just the Base64 part, and download the result. The type is re-detected from the decoded bytes rather than trusted from the string, so a data URI with the wrong declared type still saves correctly.
Does SVG need Base64 at all?
Usually not. SVG is text, so it can be embedded in CSS directly with URL encoding, which avoids the 33% penalty entirely and stays readable. Base64 is the right choice for binary formats; for SVG it is often the more expensive option out of habit.