Convert Data URI to Image
online Data URI to image decoder. Magic-byte format detection, dimension extraction, correct file download. Client-side, secure.
Paste a data:image/* URI and get a preview, real dimensions, and a correctly-named download. Detects PNG, JPEG, GIF, WebP, BMP, ICO, AVIF, and SVG by magic bytes - not just by declared MIME.
How to Use Convert Data URI to Image
- Paste the full URI into the textarea. It must start with
data:and contain a comma separating the header from the payload. - Live preview runs 250 ms after you stop typing. You'll see the image rendered below the textarea and a stats line showing declared MIME vs detected format.
- Trust the "detected" format. If the URI declares
image/pngbut the payload starts with JPEG magic bytes, the tool reports JPEG - and the download uses.jpg. Browsers do the same. - Read the stats. For PNG / JPEG / GIF / WebP / BMP the tool parses real pixel dimensions out of the file header, so you know exactly what you're looking at.
- SVG warning. If the payload is SVG (detected from
<svg>or<?xml>prefix), a warning appears explaining the<img>sandbox and reminding you not to inline untrusted SVG into a page directly. - Download - uses the detected format for the extension (
image-*.png,.jpg,.gif,.webp, etc.). Copy Data URI - places the entire URI on your clipboard.
Frequently Asked Questions
How does format detection actually work?
By reading the first few bytes of the decoded payload – the “magic number”. PNG files start with 89 50 4E 47 0D 0A 1A 0A, JPEG with FF D8 FF, GIF with GIF87a / GIF89a, WebP with RIFF ... WEBP. This is how browsers, file managers, and file(1) on Unix all do it. The declared data:image/... MIME is reported but not trusted – bytes win.
Why does this tool override the declared MIME type?
Because producers are often wrong. A codebase that hard-codes data:image/png;base64, in front of any image bytes will mislabel WebP or JPEG as PNG. Every modern browser ignores the declared MIME for <img src="data:...">` and sniffs the bytes instead, so this tool mirrors that behaviour. If declared and detected disagree, you'll see a "MIME/bytes mismatch" note in stats.
Where do the pixel dimensions come from?
From parsing the format-specific header: PNG's IHDR chunk (bytes 16-23 big-endian), JPEG's SOF0/SOF2 marker, GIF's logical screen descriptor (bytes 6-9 little-endian), BMP's DIB header, and the VP8/VP8L/VP8X sub-chunks inside WebP. For AVIF / ICO / SVG the tool falls back to whatever the browser reports after rendering.
Is it safe to preview untrusted SVG here?
In this tool, yes - the preview uses <img src="data:image/svg+xml,...">, and the HTML spec forbids script execution in images loaded via <img>. Where SVG becomes dangerous is when you inline it into a page via innerHTML or reference it with <object> or <iframe>. That's why the SVG warning banner nudges you to be careful downstream.
Why is the download named correctly this time?
Because it uses the detected format's extension. Many browser "save image as" shortcuts and naive decoders just guess .png regardless of the real bytes, which confuses image viewers that strictly check extension-vs-content. This tool always writes the correct extension.
Can I preview AVIF, HEIC, or JPEG XL via data URI?
AVIF: yes - the tool detects the format and the preview works wherever the browser has AVIF support (Chrome 85+, Firefox 93+, Safari 16.4+). HEIC: no - no browser decodes HEIC by default. JPEG XL: currently rendered only in Safari 17+ and behind flags in other browsers; the tool will still detect and offer the download.
What's the practical size limit for an image data URI?
Chrome and Firefox cap data URL length around 2 MB; Safari around 200 KB. Beyond that a real <img> on a page will fail silently. This tool's textarea can hold much more, so you can inspect huge URIs, but the preview may fail if the browser rejects the src - in that case you still get the dimensions and byte count from header parsing.
What happens if the payload is only a thumbnail preview of a larger JPEG?
Most JPEGs have their SOF marker near the end rather than the beginning, so the parser scans forward through segment lengths to find it. If the URI is truncated before the SOF marker is reached, dimensions show 0 × 0 and the browser preview may still load a partial image - a strong hint that the URI was cut off.
How is image quality preserved?
Losslessly, at the byte level. Base64 is a byte-exact encoding - decoding the same bytes back out produces the identical image file. There's no re-encode, no colour-space change, no pixel resampling. The downloaded file is a byte-for-byte copy of whatever was encoded into the URI.
Is the tool free, offline, and private?
Yes. All decoding (atob), format detection, dimension parsing, and rendering happen in your browser. No bytes are uploaded. Load the page once and it works offline indefinitely.