Data URIs: Embedding Images with Base64, and When It Backfires

A data URI lets you paste an image straight into your HTML or CSS instead of linking to a file, so the picture loads with the page and not as a separate request. It is a genuinely useful trick, and also one that quietly hurts performance when used on the wrong image. This guide covers what a data URI is, the one real benefit, the three real costs, and the simple size rule that tells you when to reach for it. Turn any image into a data URI with the Image to Base64 tool, entirely in your browser.

What a data URI looks like

A data URI packs a file's bytes directly into a string. It names the media type, says the payload is Base64, and then carries the encoded bytes:

.logo {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...");
}

The browser decodes that Base64 back into the original image without ever fetching a separate file. The same string works as the src of an img tag. Because the bytes are right there in the document, there is no second network round trip to get the image.

The one benefit: no extra request

Every separate file on a page costs a request, and a request has overhead beyond the bytes themselves: connection setup, headers, and latency. For a tiny image, that fixed cost can be larger than the image. Inlining it as a data URI folds it into a file the browser is already downloading, so the round trip disappears. For a 1-kilobyte icon, skipping a whole request is a real win.

The three costs

• It is about 33% bigger. Base64 turns every three bytes into four characters, so the inlined image is roughly a third larger than the original file. Multiply that across several images and the page weight adds up fast.
• It cannot be cached on its own. A linked image is downloaded once and reused on every page and every visit. An inlined image lives inside the HTML or CSS, so it is re-downloaded whenever that file changes. Edit one line of CSS and the browser refetches the stylesheet and every image baked into it.
• It costs CPU to decode. The browser has to decode the Base64 back to bytes before it can use the image, which burns processor time and, on phones, battery. In CSS, a big data URI can also delay the first paint, because the browser parses the whole stylesheet before it renders.

The size rule

There is a rough but reliable threshold. Below about 5 kilobytes, the request you save usually outweighs the 33% bloat, so inlining is a net win. Above about 20 kilobytes, the extra size and the lost caching clearly cost more than a saved request, so a normal linked file wins. The grey zone in between depends on how often the image changes and how many of them a page has.

A better trick for SVG in CSS

If the thing you are inlining is an SVG, Base64 is the wrong encoding. SVG is text, so you can drop it into a data URI as URL-encoded text instead, with no Base64 step at all. That avoids the 33% overhead entirely and, because the result is still text, it compresses well with gzip or brotli. For CSS background icons, a URL-encoded SVG data URI is usually the best of both worlds: no extra request and no Base64 bloat.

Generate one locally

The Image to Base64 tool builds a ready-to-paste data URI from any image in your browser, so the file is never uploaded. For the underlying format, MDN's guide to data URLs documents the exact syntax and its rules.