How to use Data URL Parser & Builder

Pick a mode — Parse to inspect a data URL, Build from text for inline HTML/CSS/JSON/SVG, or Build from file for images, fonts, and binaries.
In Parse mode, paste a `data:…` URL and watch the MIME type, charset, parameters, decoded size, and live preview appear instantly.
In Build from text mode, pick a MIME type, toggle Base64 on for binary-ish payloads or leave it off for short text, and copy the output.
In Build from file mode, drop a file — the tool sniffs the MIME from magic bytes so PNGs, JPEGs, and SVGs are identified even when the file extension is wrong. Override the MIME manually when sniffing gets it wrong.
Watch for the size warning above 100 KB — inlining large binaries as data URLs hurts page-load and blows past many browser URL limits.
Use Copy to grab the data URL or Share to produce a link that restores your text-mode session.

Data URL Parser & Builder

A single-page workbench for RFC 2397 data: URLs: parse one apart into its pieces, assemble one from a text snippet, or package an uploaded file as a self-contained base64-encoded data URL. Everything runs in your browser — no upload endpoints, no server-side MIME sniffing, no analytics on input content.

Why a dedicated Data URL tool

Data URLs sit at the awkward intersection of three specifications — URI syntax (RFC 3986), MIME types (RFC 2045), and the data: scheme (RFC 2397) — and every one of those specs has footguns. Paste a data URL into a generic URL decoder and you get a double-decoded mess. Paste it into a Base64 decoder and you lose the MIME metadata. Sniff the MIME from the extension and you get image/jpeg for the AVIF someone renamed. dev101.io ships a tool that understands all three layers at once: it walks the RFC 2397 grammar, decodes either the Base64 or the percent-encoded payload, reads the actual bytes, and sniffs the real MIME from the magic numbers at the head of the buffer.

Parse a data URL

Paste any data:… URL into the Parse tab and the tool breaks it down live:

MIME type — lowercased, defaulting to text/plain when the URL omits it (the RFC 2397 default). Unknown-but-valid MIME types are accepted as-is; the tool refuses only obviously malformed tokens.
Charset and parameters — every ;key=value pair is captured into a dict. Repeat keys resolve to the last value seen, matching how every major browser behaves. Common cases — charset=utf-8, charset=US-ASCII — are surfaced as a first-class field.
Base64 flag — a dedicated yes/no indicator so you can tell at a glance whether the payload is binary-safe.
Size in bytes — computed after decoding. Above 100 KB the tool flags the URL as "too big for the scheme" so you can reach for a real HTTP asset instead.
Live preview — image/* payloads render as an inline <img> built from a Blob object URL (never as a second data URL — that would double the memory cost). Text payloads decode as UTF-8 and display in a scrollable pane; binary payloads that aren't images fall back to a hex dump of the first 128 bytes.

Edge cases handled explicitly: empty payload (data:,), missing MIME (data:;base64,…), missing data: prefix, malformed Base64, truncated or non-hex percent sequences, and unknown-charset parameters — each produces a precise error rather than a generic parse failure.

Build a data URL from text

The Build-from-text tab is the right choice for inline SVG, scoped CSS, pre-filled JSON previews, and small HTML fragments. Pick a MIME type from the dropdown (text/plain, text/html, text/css, text/javascript, application/json, image/svg+xml), set a charset if you need one, and toggle the Base64 switch based on your payload shape:

Base64 off (percent-encoding). Keeps the output mostly readable. Only %, whitespace, and the small set of non-unreserved characters get escaped. Pick this for short ASCII text and inline SVG with mostly-ASCII content.
Base64 on. The payload is UTF-8 encoded, then Base64-encoded with the standard alphabet. Pick this for anything with a lot of reserved characters, binary-ish payloads, or content destined for a context where percent-decoding might happen twice.

The live output is always a valid data: URL — feed it back into the Parse tab to verify round-trip behaviour.

Build a data URL from a file

The Build-from-file tab reads a file locally via FileReader.readAsArrayBuffer, sniffs the MIME from the first bytes of the buffer, and emits a base64-encoded data URL. Magic-number detection covers the common web cases:

PNG — 89 50 4E 47 0D 0A 1A 0A
JPEG — FF D8 FF
GIF — GIF87a or GIF89a
WebP — RIFF…WEBP
SVG — first non-whitespace bytes match <svg or <?xml + <svg
PDF — %PDF
ICO — 00 00 01 00
WOFF / WOFF2 — wOFF / wOF2
MP3 — ID3 tag
MP4 / ISO BMFF — ftyp at byte offset 4

When the detected MIME is wrong (or missing — binary formats outside the list above fall through to application/octet-stream), the Override MIME field lets you correct it before building the URL.

Files over 100 KB trigger a warning. Data URLs for large binaries are almost always the wrong answer: the Base64 overhead adds ~33%, browsers cache them poorly, and many HTTP stacks and email clients cap URLs at 64 KB or less. Use a real HTTP asset instead.

Privacy promise

Every byte of every data URL — parsed, built, or uploaded — stays in your browser. The Share button encodes text-mode state into the URL fragment (#…), which browsers never send to servers by design. File-based data URLs are deliberately excluded from the Share state; we will not hide a binary blob in a link without explicit consent. No analytics on input content, no server MIME sniffing, no third-party scripts in the path between your clipboard and the output.

Related tools

Base64 — encode and decode raw Base64 strings with UTF-8 correctness.
URL Encode / Decode — percent-encode query strings, path segments, and form values.
Base32 — RFC 4648 Base32 for TOTP seeds and case-insensitive identifiers.

Frequently asked questions

What is a data URL and when should I use one?

A data URL (sometimes called a data URI) is a URL scheme defined by RFC 2397 that packs a tiny payload — a small image, an SVG icon, a CSS fragment — directly into the URL string instead of pointing at a separate HTTP resource. The canonical form is `data:[<mediatype>][;base64],<data>`. Data URLs shine for assets small enough that the cost of an extra network round-trip outweighs the size bloat of Base64 encoding — think 1 KB SVG icons, loading-state spinners, or inline favicons. They are also useful inside documents that must stay self-contained, such as emailed HTML reports. Do not use data URLs for large assets; the encoded payload is ~33% bigger than the raw bytes, caches poorly, and can blow past browser URL length limits.

When should I pick Base64 vs percent-encoding for a data URL payload?

Use Base64 for any binary payload — images, fonts, PDFs, audio — because percent-encoding a binary file produces a three-character escape for most bytes and bloats the URL by roughly 3x instead of Base64's 4:3. Use percent-encoding for small, mostly-ASCII text such as an inline SVG or a JSON snippet, where the output stays readable and only a handful of reserved characters (`%`, `#`, `?`, `&`) need escaping. The tool's Build-from-text mode exposes a toggle so you can compare both representations for the same input.

Why does my parser say "Malformed percent-encoding near %XX"?

RFC 2397 requires every `%` in a non-base64 payload to be followed by exactly two hex digits. A truncated sequence at end-of-string (`%A`), a non-hex character after `%` (`%GZ`), or a raw `%` that was never intended as an escape all trigger this error. The parser points at the offending window so you can fix the source. If the data URL came from a legacy system that double-encoded the payload, decode it once more — either with the URL Encode tool in Component mode, or by feeding the output back through this tool.

Is my input sent to your servers?

No. Every Data URL parse, build, and magic-byte sniff runs in your browser. File uploads are read locally with `FileReader` and never leave the tab. The Share button encodes state into the URL fragment (`#…`), which browsers never send to servers by design, so shared links keep your payload private. File-based data URLs are intentionally excluded from the Share state — we will not hide a binary blob in your URL bar without warning.