Data URI

Why It Matters

Embedding removes a request and removes a broken-image risk, and for a small icon that is a clear win. Past a certain size it stops paying. Base64 encoding inflates the data by roughly a third, so a 90 KB photograph becomes about 120 KB of text inside your HTML. That text cannot be cached separately, so every visit re-downloads it along with the page, and it cannot be cached by a second page that uses the same image. It also bloats the file you have to edit. A rough rule holds up well: inline below about 4 KB, link anything larger. Three large photos inlined is the difference between a 20 KB page and a 700 KB one.

How It Works

The parser reads the scheme, splits on the first comma, and takes everything before it as the header. The MIME type tells the browser how to interpret the bytes — get it wrong and an image renders as broken even though the data is intact. If base64 appears in the header the payload is decoded from base64 encoding; otherwise it is treated as percent-encoded text. Data URIs are their own origin for security purposes, which is why a page cannot navigate to a top-level data: URL in modern browsers and why a Content Security Policy must list data: explicitly in img-src or the image is blocked. Since the bytes are already in the file, a host simply serves the HTML and no extra request is made.

Real-World Example

Common Mistakes

• ✕Inlining large photographs — the page grows by about a third of their size and none of it can be cached separately
• ✕Writing the wrong MIME type in the header, so the browser refuses to render perfectly valid data
• ✕Forgetting to percent-encode the hash and plus characters in a plain-text SVG data URI, which truncates it at the first hash
• ✕Adding a strict Content Security Policy without allowing data: in img-src, which blocks every inlined image at once

Related Terms