Image to Base64

Base64 rewrites arbitrary bytes using 64 printable characters, taking three bytes at a time and emitting four, padding the end with one or two equals signs when the length does not divide evenly. A data URI is the envelope around that: the data: scheme, a media type such as image/png, the word base64, a comma, then the payload. The encoding alone tells software nothing about what it holds; the URI does, which is why a browser given the whole string in an img src draws it in place rather than fetching anything.

Four characters for every three bytes is a fixed third on top before the prefix is counted, and nothing avoids it — base64 is a transport encoding, not a compression one, so it can only add. Gzip and brotli claw back a useful part of that when the URI sits inside an HTML or CSS file, but never down to the original binary, which PNG or JPEG had already compressed. At small sizes the overhead rarely decides anything; what decides it is that the bytes now travel with the document rather than separately from it.

Whenever the image is large, reused, or changes on a schedule of its own. An inlined image has no cache entry, so a logo living in a stylesheet is downloaded again every time anything else in that stylesheet changes, and the same picture pasted into ten templates is ten copies. It cannot be lazy-loaded either, as there is no request to defer — everything inlined is paid for up front, and an image inside render-blocking CSS delays the first paint. Inlining wins only where a round trip would cost more than the bytes do.

Because mail clients decide for themselves what an img src may contain, and several refuse data URIs outright. Gmail's web interface and various Outlook builds are the ones people hit: the image is dropped or shows as an empty frame while identical HTML renders correctly in a browser. Some webmail also rewrites images through a proxy that understands only http addresses. Two approaches survive — a hosted image on a stable https URL, or a real attachment referenced with cid:. Test by mailing yourself in the clients your recipients use.

Nothing leaves your machine. The file is handed to the browser's FileReader, the data URI is built in the page, and the preview you see is that same string drawn by an image element — no request carries the picture anywhere, because there is no server in the path to carry it to. That matters more here than for most conversions, because the images people need as base64 are disproportionately scanned signatures, ID photographs, dashboard screenshots and unpublished artwork. A converter that uploads hands all of that to a stranger.

In HTML the whole string goes into an img element's src attribute exactly as copied. In CSS, wrap it in url(...) for background-image; quotes are optional there, as the base64 alphabet holds no spaces or brackets to confuse the parser. In JSON it is a plain string value needing no escaping. Check what the receiving API wants, though — many accept only the payload and reject the data:image/png;base64, prefix, while others require it. Wherever it goes, keep it on one line: a break inside it is fine for some parsers and fatal to others.

No. Base64 is a reversible mapping between bytes and characters, so decoding returns the original file exactly, byte for byte — same pixels, same compression artefacts, same embedded metadata. Nothing is resampled and nothing is discarded, which is also why the string can never come out smaller than the file went in, and why encoding and decoding repeatedly costs nothing, unlike re-saving a JPEG. If the string is too long, the fix sits upstream: resize the image to the dimensions it is displayed at, or compress it, then encode the smaller file.

You can, and it will draw, but base64 is usually the wrong wrapper for an SVG. An SVG is already text, so base64 makes it a third longer for no gain, where percent-encoding the markup instead — escaping the few characters that matter, chiefly the hash and angle brackets — often lands shorter than the original file and stays readable where it sits. Base64 earns its place when a field demands one opaque blob of text. Either way, an SVG loaded through an img src cannot run scripts or fetch external fonts.