Turn any image — or any file — into a Base64 data URI you can paste straight into CSS, HTML, JSON or a config file.
Embedding an image as a data URI removes one network request, which used to be a meaningful win. Under HTTP/2 and HTTP/3, requests are cheap and multiplexed, so the calculation has changed: inline only what is small and unlikely to change.
An inlined asset cannot be cached separately — every page that embeds it re-downloads it, and one changed pixel invalidates the whole file it lives in. It also inflates the document your browser must parse before rendering. For a 200-byte icon that is fine; for a 200 KB hero image it is a performance bug.
Tiny SVG icons in a stylesheet, a placeholder blur, a logo in an HTML email, an image inside a JSON API response, or an asset that must survive being copied as a single file. For everything else, ship a real file and optimise it with the image compressor or PNG to WebP instead.
A URL that carries the file itself instead of pointing at one: data:image/png;base64,iVBOR… Browsers decode it inline, so no separate HTTP request is made.
For small assets — icons, tiny textures, single-colour SVGs — where saving a request matters, or where the asset must travel inside a single HTML or CSS file. Above roughly 5 KB the 33% size penalty and the loss of caching outweigh the saved request.
Base64 represents three bytes with four characters, so encoded data is about 33% larger. Gzip or Brotli recovers some of that, but never all of it.
No. The file is read by your browser and encoded locally; nothing is transmitted.
No. Once the data URI is embedded in HTML or CSS, it shares that document’s cache entry and must be transferred again whenever the parent changes. Keep larger or frequently reused images as normal files.