Convert Image to Data URI
Convert images to base64 data URIs preserving original format. HTML/CSS/Markdown wrappers. Free, offline, client-side.
Encode an image to a base64 data: URI without silently re-encoding it as PNG (the common bug in other tools). Pick HTML, CSS, or Markdown wrapper. SVGs can use URL-encoding for smaller output.
How to Use Convert Image to Data URI
- Drop or upload an image - PNG, JPG, GIF (animation preserved), BMP, WebP, SVG, or AVIF. The dropzone supports drag-drop or click. Files stay in your browser; no upload.
- Pick output format - "Keep original" reads the file bytes directly (best fidelity, no quality loss). Re-encode to PNG/JPEG/WebP via canvas if you specifically need a different format. JPEG and WebP show a quality slider (1-100).
- Pick a wrapper - Raw gives just
data:image/png;base64,.... HTML wraps as<img src="..." />. CSS givesbackground-image: url("...");orcontent: url("...");. Markdown gives. JSON gives a properly-escaped string for embedding in config files. - SVG only - try URL-encoding - when the source is SVG, check "URL-encode instead of base64" for a smaller result (~30% less). The browser parses URL-encoded SVG data URIs equally well, but base64 is the default for other formats.
- Read the stats - original file size, data URI byte count, overhead percent, MIME type, dimensions. Base64 has a fixed ~33% overhead; URL-encoded SVG is usually smaller than base64.
- Preview before copying - the small preview pane renders the data URI exactly as a browser would, so you catch issues before pasting into production.
- Copy or download - Copy puts the wrapped string on your clipboard; Download saves
image-data-uri.txt. Ctrl+Enter (⌘+Enter on Mac) forces a recompute.
Frequently Asked Questions
What’s a data URI, exactly?
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.
Why does “Keep original” matter?
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.
What’s the size overhead of base64?
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.
Should I re-encode to WebP?
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.
Why URL-encode SVGs instead of base64?
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.
Will the data URI work in every browser?
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.
Is my image data uploaded anywhere?
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.
Does it preserve GIF animation?
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.
Can I paste an HTML wrapper directly into my code?
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.
What about HEIC photos from iPhone?
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.