A data: URL puts an entire file inside the URL itself — no request, no separate resource. Defined by RFC 2397 back in 1998, the format is:

data:[<mediatype>][;base64],<payload>

data:text/plain,hello%20world          ← percent-encoded text (no ;base64)
data:image/png;base64,iVBORw0KGgo...   ← base64 binary
data:,hello                            ← mediatype omitted: defaults to text/plain;charset=US-ASCII

The mediatype is a normal MIME type plus optional parameters (;charset=utf-8 is common for text). ;base64 is a flag on the encoding of the payload, not part of the type — which is why you never write data:image/png;base64 for a percent-encoded PNG (a hopeless format anyway; always base64 for binary).

Where they earn their keep

• Tiny inline images: a 400-byte icon inlined as data:image/svg+xml,... or data:image/png;base64,... in CSS or img src saves a whole HTTP request and renders with the first paint.
• Generated downloads: canvas.toDataURL() gives you a PNG data URL of whatever was drawn; an <a download> pointing at a blob or data URL saves a file your page just computed — no server round-trip.
• Single-file documents: a self-contained HTML report that embeds its logo, fonts and charts as data URLs travels as one file that works offline.
• Dev/testing: quick fixtures — a known 1×1 PNG (iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNkYPhfDwAChwGA60e6kgAAAABJRU5ErkJggg== is the classic) without standing up a fixture server.
• Embedding in text formats: JSON payloads and config fields that must carry binary ({"avatar": "data:image/png;base64,..."}).

The real limits

Size. Base64 costs +33% before anything else happens; the payload then lives inside HTML/CSS, so it’s parsed, held in DOM strings, and re-decoded on every render. A 500 KB image is a 667 KB string your page carries around. Rough guidance: data URLs shine below ~1–2 KB per asset, stay defensible into tens of KB, and are a mistake beyond a few hundred KB.

Caching. An inlined resource can’t be cached independently — it’s re-downloaded inside every page that carries it. The same icon as /icon.png downloads once and caches for a year; as a data URL it ships inside every HTML page forever.

Navigation blocks. Browsers block top-level navigation to data: (address bar, window.location, most programmatic redirects) as an anti-phishing measure. Subresource uses — img, CSS url(), iframe src where permitted — are unaffected, and download links work. If your “open this data URL in a new tab” code silently does nothing, this is why; use a blob URL or an <a download> click instead.

CSP and sanitizers. A strict Content-Security-Policy that lists img-src 'self' blocks data: images — img-src data: must be granted explicitly. HTML sanitizers strip them for the same reason.

Email. Many clients (Gmail included) strip data-URL images from incoming mail — use CID attachments for inline images in HTML email.

MIME correctness. A data: with the wrong mediatype renders wrong or not at all: data:text/plain;base64,... around a PNG shows garbage text, and omitting the type defaults to text/plain;charset=US-ASCII. Text payloads need their real charset or non-ASCII content degrades.

The shortcut

The tool has a Data URL output mode: pick a file (or type text) and it produces a correct data:<mime>;base64, URL — real MIME type from the file or sniffed from the magic bytes, never a guess. Pasting a data URL back into Decode strips the prefix, reports the MIME, and decodes the payload — percent-encoded forms included.

Frequently asked questions

What's the difference between data:text/plain,hello and data:...;base64,...?

Two payload encodings. Without ;base64 the payload is percent-encoded text — data:text/plain,hello%20world literally means 'hello world'. With ;base64 the payload is base64 bytes — required for images, PDFs and any binary. The decoder handles both forms and tells you which it got.

What MIME type should a data URL have?

The real media type of the payload — data:image/png;base64,... for a PNG, application/pdf for a PDF. Omit it and the default is text/plain;charset=US-ASCII, which renders binary as mojibake. When you encode a file with the tool's Data URL output, it uses the file's actual MIME (falling back to sniffing the magic bytes).

Is there a size limit on data URLs?

No single spec limit — it's per browser and per context. Legacy IE capped them at 32 KB; modern browsers accept megabytes inside img/link/CSS contexts. The practical ceiling is much lower for other reasons: the +33% base64 overhead, no independent caching, and memory spikes when big strings round-trip through the DOM. Treat a few hundred KB as the sane maximum.

Why doesn't clicking my data: link open the file?

Because major browsers block top-level navigation to data: URLs — typing, pasting or script-redirecting the address bar is refused as an anti-phishing measure (Chrome and Firefox have done this for years). Embedding in <img>, CSS, iframes' allowed contexts, and triggering a download via <a download> still work — which is why the tool's Download button uses a blob URL rather than navigating.

Do data URLs work in HTML email?

Mostly no. Many email clients — Gmail included — strip or refuse data: image sources in received HTML mail. For email, attach the image and reference it by Content-ID (cid:) instead.