When to Use Base64 Images (Data URIs)

A data URI lets you embed an image directly inside your HTML or CSS, as text, instead of linking to a separate file. It looks like this:

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

The image is the attribute. There is no file, no separate request. This sounds like a performance win, and it was once genuinely promoted as one. Today it is usually a mistake — and understanding exactly why is a good lesson in how web performance actually works.

How a data URI is built

Three parts, separated by punctuation:

• data:— the scheme, saying “the data is right here.”
• image/png;base64 — the MIME type and the encoding.
• The Base64 text of the image itself, which can run to thousands of characters.

Base64 is what makes this possible: it re-expresses arbitrary binary data using only safe text characters, so an image can live inside a text document.

The appeal: one fewer request

The original argument was about HTTP requests. Every separate file a page loads costs a round trip to the server, and under old HTTP/1.1 browsers could only run about six of those at once. A page with fifty small icons would queue them up, and the page would crawl.

Inlining an image removes its request entirely — it arrives with the HTML or CSS that references it. Fewer requests, faster page. That reasoning was sound.

It has since been largely dismantled, for three separate reasons.

Problem 1: it makes the image 33% bigger

Base64 expands data by roughly a third. This is not a flaw; it is arithmetic. Base64 turns every 3 bytes into 4 characters, so the output is always about 133% of the input.

So a 30 KB image becomes about 40 KB of text embedded in your page. You saved one request and paid 10 KB for it.

Problem 2: it destroys caching (this is the serious one)

This is the argument that really settles it, and it is the one people overlook.

A normal image file is cached independently. Your visitor downloads your logo once, and on every subsequent page — and every subsequent visit — the browser reuses it from cache. Zero bytes, zero time.

An inlined image cannot be cached separately, because it is not a file. It is part of the HTML or the CSS. Which means:

• If it is in your HTML, and your HTML is dynamic (as most pages are), it is re-downloaded on every single page load. Your logo, embedded on ten pages, is downloaded ten times. As text. At 133% of its size.
• If it is in your CSS, it is cached with the stylesheet — but it also bloats that stylesheet, and CSS is render-blocking. The browser will not draw a single pixel of your page until the CSS has finished downloading. So you have taken an image that could have loaded lazily, in the background, and put it directly onto the critical path.

That second point is the real damage. You have made the page appear slower — a worse Largest Contentful Paint — in exchange for saving a request that was never the bottleneck.

Problem 3: HTTP/2 removed the original justification

The request-cost argument was a workaround for an HTTP/1.1 limitation. Under HTTP/2 and HTTP/3 — which essentially every site now uses — requests are multiplexed: many files stream over a single connection in parallel, with very little per-request overhead.

The problem inlining was invented to solve has largely been solved at the protocol level. The cure is now worse than the disease.

So when is it actually a good idea?

There remain a few legitimate cases, and they share a shape: tiny, and needed immediately.

• Very small images — under about 1–2 KB. A tiny icon, a bullet, a gradient. At that size the 33% penalty is a few hundred bytes and genuinely irrelevant.
• Critical above-the-fold images, where you want to eliminate a round trip for something the user sees instantly.
• Low-quality image placeholders. A well-established technique: inline a tiny, blurry version of a hero image so something appears immediately, then load the real one over it.
• Self-contained files. An HTML email, a single-file report, or a document that must work with no external assets. Here inlining is not an optimisation — it is a requirement.
• Avoiding a flash of missing icon for a handful of critical UI symbols.

A reasonable rule of thumb: inline if under about 2 KB and needed immediately. Otherwise, use a normal image file.

And note that for icons and simple shapes, inline SVG usually beats an inline Base64 raster outright: it is smaller, it is text already (so it compresses well rather than expanding), and it scales perfectly to any size.

Other downsides worth knowing

• It is unreadable. Thousands of characters of noise in the middle of your source makes the file painful to work with and to review.
• Updating it means editing code. Changing a normal image is replacing a file. Changing an inlined one is a code change and a redeploy.
• It cannot be lazy-loaded. An inlined image is downloaded whether or not the user ever scrolls to it.
• Content Security Policy sometimes restricts data: URIs.

Frequently asked questions

Does Base64 make images smaller? The opposite — about 33% larger.

Do data URIs hurt SEO? Indirectly. Bloating render-blocking CSS slows your page, and page speed is a ranking signal. An inlined image also cannot be indexed by image search.

What is the size limit? There is no hard limit in modern browsers, but anything above a few kilobytes is almost certainly the wrong choice.

Is Base64 encryption? No — none whatsoever. Anyone can decode it instantly. It is purely an encoding for transport.

Convert an image to Base64

Use our Image to Base64 converter to generate a data URI in your browser — nothing is uploaded. Shrink the image first with the Image Compressor, because the smaller the source, the less the 33% penalty costs you. For the encoding itself, read what Base64 encoding is.