Image ↔ Base64
Inline an image, or decode one back out
Produce a data URI ready to paste into CSS or HTML, or paste a Base64 blob and get the file back.
Image ↔ Base64
Runs in your browser · nothing uploaded01 — How to use Image ↔ Base64
02 — Getting good results
03 — Questions
No. The file is read with the browser's own file API and encoded in this tab. Nothing is transmitted, which is the point when the image is a client logo or an unreleased asset.
Because inlining is only a good trade for small files. A data URI is re-downloaded with every copy of the page that references it, cannot be cached independently, and blocks rendering while it is parsed. Past a couple of megabytes a normal image request is faster.
It still works. The bytes are decoded and the format is identified from its magic numbers — the signature at the start of a PNG, JPEG, GIF, WebP or AVIF file — so the download gets the correct extension.
No. Base64 is a lossless re-encoding of the exact bytes. Decoding the result returns a file byte-for-byte identical to the original, with no recompression and no quality loss.
04 — More about Image ↔ Base64
When inlining an image is worth it
A data URI trades a network request for page weight. That is a good trade when the request would cost more than the bytes: a 300-byte icon inlined into CSS saves a round trip that might take 50 milliseconds, and the 100 bytes Base64 adds are irrelevant. It becomes a bad trade quickly as files grow, for reasons that compound. The encoded image cannot be cached separately, so every page that embeds it re-downloads it and a change to any part of the stylesheet invalidates the lot. It cannot be loaded lazily or served in a different format to browsers that support one. And because it lives inside a render-blocking resource, the browser must parse all of it before drawing anything. The rule of thumb that has survived is a few kilobytes: below that, inline freely; above it, let the image be an image.
Why the overhead is exactly a third
Base64 maps every three bytes of input onto four characters of output, because four six-bit groups hold exactly the same information as three eight-bit bytes. That ratio is fixed: four over three is a 33.3% increase, plus up to two padding characters and whatever line breaks are added. It is not compression and cannot be tuned — any tool claiming a smaller Base64 is either omitting padding, stripping line breaks, or compressing the source first. The last of those is the useful one: run an image through a compressor before encoding it, and the saving comes from the image being genuinely smaller, not from the encoding being cleverer.
61 more tools
where this came from.
Same shell, same shortcuts, same promise: nothing leaves your browser.