Convert Data URI to ASCII

Per RFC 2397 (1998): data:[<mediatype>][;base64],<data>. Mediatype is type/subtype with optional ;parameter=value segments (typically ;charset=X). If the mediatype is missing, the default is text/plain;charset=US-ASCII. The ;base64 marker signals Base64 encoding; otherwise the payload is URL-encoded.

For binary or dense data. Base64 expands the payload by ~33%, but every byte maps to a safe URL character. Percent-encoding only escapes special bytes, so it’s smaller for ASCII-heavy text but balloons when escaping multi-byte UTF-8 or binary (each byte becomes %XX, a 3× increase). Short English text → URL-encode. Emoji, binary, or random bytes → Base64.

It tells the decoder which byte-to-character mapping to apply after Base64 decoding. charset=utf-8 produces Unicode; charset=windows-1252 produces Windows Latin-1; charset=iso-8859-1 produces plain Latin-1. This tool honours the declared charset via the browser’s TextDecoder. If the charset isn’t recognised, it falls back to UTF-8.

Technically RFC 2397 Base64 uses the standard alphabet (+ / /). But URL-safe Base64 leaks into data URIs in the wild, so this tool normalises - → + and _ → / before decoding. Missing = padding is also added automatically.

The URI spec doesn’t impose one, but browsers do. Chrome / Firefox cap data URL length around 2 MB per URL, Safari around 200 KB. Beyond that, an image or font loader silently fails. This decoder handles whatever you paste in, but if you got the URI from a page that loaded it, it was probably under those limits.

Because it is binary, not text. A data:image/png;base64,... URI contains raw PNG bytes after decoding – intentionally not human-readable. The stats panel flags this with “looks binary” when the decoded bytes contain NULs or many high bits but the declared mediatype is text/*. For images, use a data-URI-to-image viewer instead of a text decoder.

Nothing – “data URI” and “data URL” are used interchangeably. RFC 2397 officially uses “URL” in the title but “URI” in the body. In modern browsers the URL constructor accepts them; they’re a first-class scheme just like http: or mailto:.

The decoded bytes contained sequences that aren’t valid in the declared charset (commonly: Base64-decoded bytes decoded as UTF-8 when they were actually some other encoding). TextDecoder substitutes each invalid sequence with U+FFFD (�). If you see many, try a different charset or check whether the URI was truncated.

A common bug elsewhere: some tools decode data URI payloads by first replacing + with space (the application/x-www-form-urlencoded rule). That corrupts Base64. This decoder uses atob directly on Base64 branches, so + stays as the Base64 char 62. URL-encoded branches go through decodeURIComponent which does NOT replace + with space (that’s decodeURI / form-decoding behaviour), so they’re also safe.

Yes. It runs entirely in your browser with atob, TextDecoder, and decodeURIComponent – all native APIs. No URI is uploaded, no decoded text is logged. Load the page once and the tool keeps working offline indefinitely.