Embedding images as Base64 data URIs: when it helps and when it hurts

A data URI lets you put an image directly inside your HTML or CSS instead of linking to a separate file. The image becomes a long Base64 string that the browser decodes in place. It is a genuinely useful technique, and also one that is easy to overuse.

What a data URI looks like

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...">

The pieces are the scheme (data:), the MIME type (image/png), the encoding (base64), and then the encoded bytes. The same form works in CSS: background: url(data:image/svg+xml;base64,...). The browser needs no extra network request; the image is already in the document.

The trade-off

Base64 is not compression. Encoding inflates the data by roughly 33 percent, because it represents three bytes of binary in four text characters. So an inlined image is always larger than the original file. What you save is the round trip: no separate HTTP request, no extra connection setup.

That trade is worth it for small, frequently used assets and costly for large ones.

When to inline

• Good fits: tiny icons, a logo in an email, an SVG used once, or an image you need to be present the instant the HTML loads with no second request.
• Poor fits: large photos, anything reused across many pages, or assets that benefit from browser caching. An inlined image cannot be cached on its own; it is re-downloaded with every copy of the page that contains it, and it cannot be cached by a CDN as a separate object.

A practical rule: inline assets under a few kilobytes, link to anything larger. For email specifically, inlining or hosting both have quirks, so test in real clients.

You can convert any image to a ready-to-paste data URI, and decode one back, with the Image to Base64 tool. It runs entirely in your browser, so the image is never uploaded. If you are working with raw Base64 text rather than images, the Base64 is not encryption post is worth a read.