Base64 is not compression. It is the opposite.
This trips up almost everybody the first time, so be clear about it before you use the output.
Base64 exists to carry binary data through places that only accept text. It does that by spending four characters on every three bytes, which means everything it touches gets about a third bigger. A 30KB PNG becomes roughly 40KB of characters.
For very small files it is worse than a third, because the data:image/png;base64,prefix is a fixed cost that a tiny payload cannot spread out. Encode a 40 byte image and the overhead is most of the result.
So the readout above shows both numbers and the percentage between them, rather than handing you a wall of text and letting you find out later.
The cost that does not show up in the file size
An external image is a separate file with its own URL, which means the browser can cache it. Downloaded once, reused everywhere, kept between visits.
An inlined image has no URL of its own. It is part of the document, so it is downloaded again every time that document is, and it cannot be shared between documents. Put a 40KB logo inline on ten pages and you have sent it ten times instead of once.
There is a second cost. A data URI in a stylesheet sits in the middle of a file the browser has to parse before it can render anything, so a large one delays the page rather than just adding to it.
When it is the right answer
Small and used once. An icon, a texture, a bullet, a spacer. Under about two kilobytes the saved network request is worth more than the extra third.
When there is nowhere to put a file. A single self-contained HTML document, a generated report, an email template, a config file, somewhere a build step does not exist. This is the strongest reason and it has nothing to do with performance.
When the asset pipeline is the problem. Sometimes getting one small image deployed and served with the right headers is more trouble than the image is worth.
Not for photographs, hero images, anything over about ten kilobytes, or anything that appears on more than one page.
Why it silently does not work
When a data URI fails, it usually fails invisibly, which makes it annoying to debug.
The most common cause is a Content Security Policy. A policy containing img-src 'self' blocks data URIs, and the image simply does not appear. It needs data: adding to that directive. This catches people out because it works perfectly on their machine and not on the deployed site.
The second most common cause is line wrapping. Something in the chain, an editor, a mail client, a config parser, has broken the URI across lines and inserted whitespace into the middle of it. The decoder on this page tolerates that and tells you when it has found it.
The third is Markdown or a template engine sanitising data URIs out entirely as a security measure. Test it where it is going to live rather than in a preview.
SVG is the special case
If you are encoding an SVG, base64 is usually the wrong choice and almost every tool does it anyway.
An SVG is already text. It can go into a data URI percent-encoded, which escapes only the few characters that would break the URI, typically producing something shorter than base64 would.
More usefully, it stays readable. A percent-encoded SVG in your stylesheet can be understood, searched, diffed in version control and edited in place. A base64 one is an opaque block that has to be decoded before anybody can tell what it is or change its colour.
Watch for the hash character. A colour like #ff0000 inside an unescaped SVG data URI truncates the whole thing at that point, because a hash starts a fragment. That is one of the most common ways an inline SVG breaks, and it is handled here.
Both directions, and nothing uploaded
The second tab takes a data URI and gives you the image back, along with what type it really is and how big it decodes to. Useful when something has handed you a blob of base64 and you want to know what it contains before trusting it.
All of it runs in your browser. Which matters here more than on most pages, because the output of this particular conversion is a complete copy of your file in text form, and pasting a client's logo or a signature image into an online converter hands exactly that to somebody else's server.
Common questions
Does base64 make the image smaller?
No, it makes it about a third bigger, and this is the most common misunderstanding about it. Base64 spends four characters carrying every three bytes, so a 30KB image becomes roughly 40KB of text. It is a way of putting binary data somewhere that only accepts text, not a way of compressing anything.
When is inlining an image actually worth it?
When the image is small, appears once, and saving a network request matters more than the extra bytes. A tiny icon in a stylesheet, a logo in a single-page document, a spacer, a texture. The saving is one round trip to the server, which on a slow connection can be worth more than the 33% of extra data.
Why do people say inlining hurts performance?
Because an inlined image cannot be cached on its own. An external file is downloaded once and reused on every page that references it. Inline the same image and it is re-sent inside every page that contains it, so a ten-page site sends it ten times. It also blocks: the browser cannot start rendering the stylesheet or the HTML until it has parsed all of the data URI sitting in the middle of it.
My data URI shows nothing on my site. What is wrong?
The most likely cause is a Content Security Policy. A policy with img-src 'self' blocks data URIs, and the image just does not appear with no obvious error. You need data: added to that directive. The second most likely cause is that something wrapped the URI across lines, which breaks it.
Should I base64 an SVG?
Usually not. An SVG is text already, so it can go into a data URI percent-encoded, escaping only the handful of characters that would break the URI. That is normally shorter than base64 and it stays readable, so you can see and edit the SVG in your stylesheet rather than looking at a wall of random characters. This tool offers both and tells you which is smaller.
Is my image uploaded to convert it?
No. The file is read by your browser and encoded on your device. That matters more than usual here, because the whole output is the file itself in text form, and pasting a client logo or a signature image into a random online converter puts a complete copy of it on somebody else's server.