Data URI decoder

media type · real size · preview · download · nothing is navigated to

A data: URI is a file pretending to be a link, and pasting one into the address bar to find out what it holds is exactly the wrong way to open something you did not make. This reads it instead: what it claims to be, what the bytes actually are, how big it really is once decoded, and a preview rendered locally from a blob.

How to read a data URI

1. Paste the whole thing, from data: to the end. Surrounding quotes, angle brackets or a CSS url(…) wrapper are trimmed for you.
2. Read the table. The media type is what the URI claims; bytes look like is what the payload really is, from its magic number. When those two disagree, that is the interesting part.
3. Text-ish payloads are decoded into the box below. Binary ones are not — use Download the file and open it with something that knows the format.
4. Images are previewed from a local blob. Nothing is requested from the network and the page is never navigated to the URI.

What the parts mean

RFC 2397 defines the shape as data:[<mediatype>][;base64],<data>. Every part before the comma is optional, which is why so many of these look malformed and are not:

• No media type at all — data:,Hello is legal and means text/plain;charset=US-ASCII. It is decoded here as text.
• No ;base64 — the payload is percent-encoded instead. For SVG and other markup this is usually smaller than Base64, which is why build tools emit it.
• Extra parameters — ;charset=utf-8 is the common one, and it is honoured when decoding the text.
• URL-safe Base64 — - and _ instead of + and /, often with the = padding stripped. Not strictly legal in a data URI, common anyway, and accepted here.

The size question

The reason to decode a data URI is almost always that something is too big, and the number that matters is not the length of the URI. Base64 costs about 33% on top of the raw bytes, plus the header, plus whatever your CSS minifier could not compress. The table gives both figures and the overhead between them, so you can decide whether inlining that icon is still paying for itself.

For the other direction — turning a file into a data URI, and comparing Base64 against percent-encoding for SVG — use the data URI builder.

Why the type declaration is worth checking

A data URI is entirely self-declared. The media type is a string chosen by whoever wrote the URI, and nothing in the format verifies it against the payload. So this page reads the first bytes and says what they actually are: a PNG signature, a JPEG marker, %PDF, a ZIP header — and flags it when that disagrees with the header.

Two of those disagreements matter. A data:text/html URI carries markup that runs scripts, which is why every current browser refuses to navigate to one at the top level. And a PK ZIP header under an image media type is a container, not a picture — .docx, .xlsx and .epub are all ZIPs. Neither is decided for you here; the point is that you can see it before you open anything.

What it will not do

• It does not fetch anything. A data URI has no host and there is nothing to request. The image preview is built from a local blob.
• It does not run anything. HTML and JavaScript payloads are shown as text, never executed and never rendered.
• It does not repair a broken payload. A truncated Base64 string is reported as truncated rather than silently padded into something that decodes to nonsense — the usual cause is a URI that got line-wrapped by an editor or cut off by a field limit.

FAQ

Related URL tools