Choose an image and get it as a data URI, ready to paste into HTML, CSS or JSON. You also see the size after encoding — the number that decides whether inlining is a good idea.
Runs entirely in your browser — nothing you enter here is sent to a server.
A data URI puts a file's contents directly into the place where a URL would normally go. Instead of src="logo.png", which makes the browser fetch another file, you write src="data:image/png;base64,iVBORw0…" and the image travels inside the HTML or CSS itself. The format is data:, the media type, ;base64, a comma, and then the file encoded as Base64 text.
The appeal is one request fewer. The price is size: Base64 represents every three bytes as four characters, so the encoded image is about a third larger than the file — and it can no longer be cached on its own, loaded lazily or served from a CDN separately from the document that contains it.
Tiny icons, a one-pixel placeholder, a small logo in an HTML email or a single-file report — anything of a few kilobytes that must work without extra requests.
Photos and anything above roughly 10 KB. They bloat the HTML or CSS, delay rendering and are downloaded again whenever the page changes.
SVG is text already. It can be inlined as markup, or URL-encoded in a data URI without Base64, which is smaller and stays readable.
A strict CSP blocks data URIs unless img-src or font-src lists data:. If an inlined image does not show, check the policy.
Less than it used to. Under HTTP/1.1 every extra request was costly, and inlining small images was standard advice. With HTTP/2 and HTTP/3, many files share one connection, so the saving is small and the loss of caching usually outweighs it. Inline what is critical and very small; leave everything else as files with long cache lifetimes. The verdict shown above uses that rule of thumb: under 4 KB yes, up to 10 KB only when it is needed for the first paint, beyond that no.
Convert it to a data URI and use that as the src attribute: <img src="data:image/png;base64,…">. The "HTML img" output gives you the complete tag.
Base64 encodes three bytes of data as four text characters, so the result is about 33% larger. Compression on the server recovers part of that, but not all.
Modern browsers accept data URIs of many megabytes, so the limit is practical rather than technical: large ones slow down parsing and cannot be cached separately.
No. The file is read by your browser and encoded locally; it never leaves your computer.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.