Data URI Viewer

Paste a data: URI and turn it back into something you can see. The viewer parses the media type, charset, and whether the payload is base64 or percent-encoded, decodes it, and reports the real decoded byte size. It then previews by type — images render as an <img>, SVG renders safely, text shows escaped — and a single button saves the decoded bytes as a proper file with the correct MIME type. Decoding happens entirely in your browser, so an inlined asset never leaves your machine.

How to use the Data URI Viewer

Paste a complete data: URI into the box. The viewer parses it the moment you stop typing and shows a summary panel with the media type, the charset (if one is declared), whether the payload was base64 or percent-encoded, and the size of the decoded bytes — which is usually smaller than the URI string itself, especially for base64. Anything malformed produces a clear error rather than a blank screen.

What appears below the summary depends on the type. An image/* URI is drawn as an image so you can confirm it is what you expected; an image/svg+xml URI is rendered through an image element rather than injected into the page, which keeps any script inside the SVG from running. A text/* payload is shown as escaped text, and anything else falls back to a short hex-and-snippet preview of the first bytes. Use the Download as file button to save the decoded payload locally with the right extension and MIME type, which is handy for extracting an inlined icon, font, or stylesheet back into a standalone file. All of this runs client-side, so the example works offline and your data is never transmitted.

What a data URI is, and when to use one

A data URI embeds a small file directly inside a URL instead of pointing at one. Defined by RFC 2397, its shape is data:[<mediatype>][;base64],<data>. The media type is an ordinary MIME type such as image/png or text/css, optionally carrying parameters like ;charset=utf-8. If the literal token ;base64 appears, the data after the comma is Base64; if it does not, the data is plain text with any unsafe bytes percent-encoded the same way they would be in a normal URL. When the media type is omitted entirely it defaults to text/plain;charset=US-ASCII.

The two encodings exist for different payloads. Percent-encoding is compact for mostly-textual content — a snippet of SVG or CSS stays human-readable with only a few characters escaped. Base64 is the right choice for binary content like PNG or WOFF data, because it maps arbitrary bytes onto a safe 64-character alphabet that survives being pasted into HTML or CSS. The cost of that safety is size: Base64 inflates the data by roughly 33 percent, since every three bytes become four characters. That overhead is the main reason large images are a poor fit for data URIs.

Inlining shines when the win is avoiding a round trip. A tiny icon, a background gradient SVG, or a critical above-the-fold image embedded as a data URI loads with the document and paints without a second HTTP request, which can matter on high-latency connections. The trade-offs are real, though: inlined assets cannot be cached separately, so they are re-downloaded with every page and bloat the HTML or CSS that carries them; the base64 tax makes that worse. The rule of thumb is to inline only small, rarely-changing assets, and to serve anything larger or reused across pages as a normal cacheable file. This viewer is the inverse operation — taking a data URI someone handed you and recovering the original file to inspect or save it.

Common use cases

  • Extracting an inlined asset. Recover an icon, font, or image embedded in CSS or HTML back into a real file.
  • Checking what a URI contains. Confirm the media type, encoding, and decoded size before trusting or shipping it.
  • Previewing safely. See an inlined image or SVG without pasting it into a live page where scripts could run.
  • Debugging build output. Inspect data URIs a bundler produced to verify the right files were inlined.
  • Private decoding. Decode a URI locally instead of pasting potentially sensitive content into an online decoder.

Frequently asked questions

What data URI shapes are supported?

The full RFC 2397 form: data:[][;base64],. It handles a declared charset, an omitted media type (which defaults to text/plain), base64 payloads, and percent-encoded text payloads.

How does it decide how to preview?

By media type. image/* renders as an image, image/svg+xml renders via an image element (so embedded scripts cannot run), text/* shows as escaped text, and anything else gets a short hex-and-text snippet of the first bytes.

Why is the decoded size smaller than the URI?

Base64 expands binary data by about a third, so the encoded text in the URI is larger than the bytes it represents. The viewer reports the true decoded byte count, which is what the saved file will be.

Can I save the payload as a file?

Yes. The Download as file button writes the decoded bytes to a Blob with the parsed MIME type and triggers a download with a sensible extension, letting you turn an inlined asset back into a standalone file.

Is anything I paste uploaded?

No. Parsing, decoding, preview, and download all happen in client-side JavaScript in your browser. The data URI is never sent to any server, so its contents stay on your device.