Nothing is uploaded
The encoding is done by FileReader, a browser API that reads a file the user picked and hands back its bytes. That call does not touch the network. No request goes out when you choose a file, and none goes out when the result appears — open the network tab in your dev tools and watch it stay empty, or pull the network connection and use the tool anyway. It works offline because there is nothing on the other end.
Why it grows by a third
Base64 takes three bytes, twenty-four bits, and rewrites them as four characters of six bits each. Four characters where there were three bytes is a ratio of 4:3, so every file inflates by exactly 33.3% before anything else is counted. Then the data:image/png;base64, prefix is added on top, and if the input length is not a multiple of three you get one or two = padding characters at the end.
Gzip or Brotli on the wire claws some of that back, because Base64 text compresses better than the raw binary did. It does not claw all of it back, and it does nothing for the memory the string occupies once decompressed, or for the time the parser spends walking past it.
When inlining actually helps
The case for a data URI is one fewer HTTP request. That mattered a great deal under HTTP/1.1, where six connections per host was the ceiling and every small icon queued behind something. Under HTTP/2 and HTTP/3 requests are multiplexed and the saving is much smaller.
What has not changed is the caching cost. A separate image file gets its own cache entry with its own lifetime, and a hundred pages referencing it download it once. An inlined image is part of whatever document carries it: change one word of the HTML and the image is re-sent; use the same image on ten pages and it is stored ten times. So the rule of thumb is small and page-specific, inline; anything reused, or anything over roughly ten kilobytes, keep as a file.
Practical size ceilings
A data URI in an src or a stylesheet has no formal length limit in modern browsers, which is why multi-megabyte strings mostly work. Other places are stricter. Anything that routes the URI through an actual address bar or a redirect hits limits between roughly 2 KB and 64 KB depending on the browser and any proxy in the path. Email clients vary wildly and several ignore data URIs in <img> entirely. If the string is going anywhere other than a stylesheet or an HTML document you control, test it in the destination before committing to the approach.
SVG is a special case worth knowing
An SVG is already text. Base64-encoding it makes it a third bigger for no benefit. Percent-encode it instead — data:image/svg+xml,%3Csvg... — and the result is smaller than the original file was, and still readable when you open the stylesheet six months later. The characters that must be escaped are #, %, and whichever quote character encloses the URL. Base64 still works for SVG; it is just the worse of the two options.
Questions people ask
Does encoding a file this way protect or hide it?
No, and it is worth being blunt about that because the assumption is common. Base64 is a notation, not encryption. Anyone who can see the string can paste it into a decoder — or into this site's own reverse tool — and get the exact original file back, bytes identical. There is no key and no obscurity worth relying on. If an image needs to be restricted, that is an access control problem on the server, not a formatting one.
The copy button did not paste the whole thing.
Some applications cap what they will accept from the clipboard, and a multi-megabyte string can be truncated silently on the way in. A truncated data URI usually shows as a partly drawn image or nothing at all. Select the text in the box and copy it manually, or better, reduce the file first — anything large enough to break the clipboard is far too large to be inlining in the first place.
Is the image quality affected?
Not at all. This path never decodes the image to pixels; it reads the raw bytes off disk and rewrites them in a different alphabet. Decode the result and you get the original file back byte for byte, same compression artefacts, same everything. That is different from the resize, crop and rotate tools here, which do go through a canvas and therefore do re-encode.
Why does my transparent PNG show a white box in my editor?
The data URI is fine — the transparency is in the bytes and survives. What you are seeing is whatever renders the preview drawing it against a white background. Put it on the page and check it there against the real backdrop before concluding anything is wrong with the encoding.