Convert Data URI to ASCII
online Data URI decoder. RFC 2397 compliant, handles Base64 and URL-encoded payloads. Client-side, instant, secure - no uploads.
Decode a data: URI (RFC 2397) and reveal the text payload. Handles Base64, URL-encoding, and the full mediatype header including charset. Runs entirely in your browser.
How to Use Convert Data URI to ASCII
- Paste the full URI into the input. It must start with
data:and contain a comma separating the header from the payload. - The tool auto-detects the media type, charset, and whether the payload is Base64 or percent-encoded from the header. You don't need to pick a mode.
- Optional: Strip UTF-8 BOM. If your Base64 payload starts with the three bytes
EF BB BF, enabling this toggle removes the resulting BOM character from the decoded text. - Press "Decode" (or Ctrl+Enter). Live preview also runs 200ms after you stop typing. Stats below the output report media type, charset, encoding branch, input chars, output bytes, and any U+FFFD replacement characters.
- Watch for warnings. If the decoded bytes contain NULs or many high-bit bytes but the media type is
text/*, stats show "looks binary" - a hint that the URI actually carries image or other non-text data. - Copy or download. Copy places the decoded text on your clipboard. Download saves a
data-uri-decoded-*.txtfile.
Frequently Asked Questions
What’s the RFC 2397 format exactly?
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.
Why would a URI use Base64 instead of percent-encoding?
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.
What does the charset parameter control?
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.
How does this handle URL-safe Base64 with – and _?
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.
What’s the practical size limit for data URIs in browsers?
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.
Why does my image data: URI look like gibberish?
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.
What’s the difference between a data: URI and a data: URL?
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:.
What do U+FFFD replacement characters in the output mean?
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.
Can plus signs in the Base64 payload be mistaken for spaces?
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.
Is the tool free, offline, and private?
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.