Data URI Decoder

Paste a data: URI to see its declared media type, its parameters (such as charset), whether the payload is base64 or percent-encoded, the decoded byte length, and a hex preview of the first 16 bytes. For textual media types (text/*, application/json, +xml, +json, image/svg+xml, application/javascript) the decoded text is also shown, with the encoding used to decode it.

Parsing follows RFC 2397 (checked 2026-09-02); when the media type is omitted the default text/plain;charset=US-ASCII is reported and flagged as a default. The URI is first read the way a browser's URL parser reads it: tab, LF and CR are removed everywhere, spaces and control characters at the very end are removed, and text after a raw # is the URL fragment, not payload (write %23 for a literal #). Each such removal is listed with the result. Chromium-based browsers are the exception for tab, LF and CR: they keep them as bytes, which the note points out. Before the data: scheme the URL parser strips control characters and spaces (U+0000–U+0020) only; other whitespace there, such as U+00A0 or U+FEFF, is removed only as a paste helper and noted, because a browser rejects a URI that starts with it. All other characters of the payload, including leading and inner spaces, are data.

The payload is base64 when the part before the comma ends with ;base64, matched case-insensitively and allowing spaces after the semicolon and before the comma, as browsers do (WHATWG Fetch); data:base64, without the semicolon is not base64. A base64 payload is percent-decoded first, as browsers do, so %3D is a padding = and %20 a space; it is then validated for RFC 4648 structure (alphabet, padding placement and count, and a possible final quantum); ASCII whitespace (tab, LF, FF, CR, space) inside a base64 payload is ignored, as browsers do, but other whitespace such as a no-break space (U+00A0) is rejected as an invalid character. In a percent-encoded payload, raw non-ASCII characters are read as their UTF-8 bytes, as browsers do after URL parsing, so data:,あ and data:,%E3%81%82 give the same bytes (E3 81 82); a % not followed by two hex digits is kept as a literal %. An unpaired UTF-16 surrogate has no UTF-8 form and is rejected instead of being replaced with U+FFFD (checked against the WHATWG Fetch data: URL processor on 2026-10-12).

Text view (checked 2026-10-20 against the WHATWG Encoding, Fetch, and MIME Sniffing standards): the bytes are decoded with this browser's TextDecoder for the declared charset. Labels follow the WHATWG Encoding Standard — case-insensitive, surrounding whitespace ignored, aliases included — so iso-8859-1, latin1, and us-ascii decode as windows-1252 (0x80 is €), and Shift_JIS, sjis, and windows-31j as Shift_JIS. A label TextDecoder does not accept (an IANA-only alias such as csUTF8, or ISO-2022-KR and HZ-GB-2312, which map to the replacement encoding), a charset given twice, or charset= in place of the media type (data:charset=…) is reported and the text is not shown; the byte count and hex preview stay.

Without a charset, an omitted media type uses the RFC 2397 default US-ASCII and text/plain uses the RFC 2046 / RFC 6657 default US-ASCII (both decoded as windows-1252, as in browsers, with a warning when a byte is above 0x7F); JSON (application/json, +json) and JavaScript use UTF-8 (RFC 8259, RFC 9239). Other textual types (text/html, text/css, XML, SVG, …) take their encoding from the content or the context, which this tool does not read, so they are shown as UTF-8 marked as assumed. A declared charset is used as given for every textual type: type-specific rules such as JSON ignoring the charset parameter or a BOM taking precedence over it are not applied, and the decoder is never chosen from the bytes.

Malformed byte sequences are shown as U+FFFD with a warning. A leading U+FEFF that a UTF-8 or UTF-16 decoder treats as a byte order mark (EF BB BF, FF FE, FE FF) is left out of the decoded and copied text, as TextDecoder does by default, with a note; the byte count and hex preview still include it.

This tool reports only what the URI declares and never infers a media type from the decoded bytes. Input is capped at 2 MiB.