Convert Image to Data URI

A URI scheme that embeds resource data inline. Format: data:<mime>[;base64],<data>. For images that means the bytes of the image arrive as text – no separate HTTP request needed. Great for tiny icons and inline SVG; impractical past a few MB because the base64 overhead bloats your HTML/CSS.

Many online “image to data URI” tools secretly re-encode everything as PNG via canvas. A 50 KB JPEG becomes a 200 KB PNG data URI – 4× bigger for no benefit. We default to reading the file’s raw bytes via FileReader, so a JPEG stays JPEG and an animated GIF stays animated.

Exactly 4/3 ≈ 33%. Three input bytes become four output characters. So a 10 KB image becomes a ~13.4 KB base64 string. Add a few bytes for the MIME prefix. The stats line reports the exact overhead so you can decide if it’s worth inlining.

If the original is a JPEG and your audience uses modern browsers, often yes – WebP at quality 75 typically beats JPEG quality 80 in both size and clarity. But if the source is already optimized (e.g., from Squoosh), re-encoding may make it worse. Compare the stats before committing.

Base64 makes SVGs bigger than they need to be because SVG is already text. URL-encoding just escapes the few reserved URL characters (<, >, #, etc.) and leaves the rest as readable XML. Browsers parse both, and URL-encoded SVG data URIs are typically 30% smaller and easier to debug.

Modern browsers, yes. Internet Explorer 8 had a 32 KB limit on data URIs (gone in IE9+). All modern browsers (Chrome, Firefox, Safari, Edge) accept multi-MB data URIs, but very large ones slow down page parsing and inflate CSS. Keep inline assets under ~10 KB unless you have a specific reason.

No. FileReader, Canvas (when re-encoding), and string operations all run locally. Open DevTools → Network and watch zero requests fire after the page loads. Safe for client work, watermarked masters, or proprietary assets.

Yes – when “Keep original” is selected. The browser reads the raw GIF bytes and base64-encodes them directly. Re-encoding through canvas would freeze the GIF to its first frame because canvas treats <img> as a static still.

Yes. The HTML wrapper output is a valid self-closing <img> tag. The CSS wrappers are valid CSS declarations. The Markdown wrapper is a valid image syntax. Just paste into whichever target you’re working in.

HEIC can only be decoded by Safari natively (and only on macOS / iOS where the OS provides the codec). On Chrome/Firefox/Edge, HEIC files will error. Convert to JPEG or HEIF-as-AVIF first, then come back.