Base64 vs Plain Image Files: What's Faster and When

Two ways to wire up an image

First, an important point: these are not two different image formats. Both the file and the Base64 string hold the exact same image bytes. Only the delivery differs. A file is a separate resource on the server that the browser fetches by link. Base64 is the same data rewritten as text and pasted straight into the HTML or CSS.

If you want to refresh exactly how the encoding works, see "What is Base64." Here we'll run an honest comparison of the two approaches across three key metrics.

<!-- Option 1: a link to a file -->
<img src="/img/logo.png">

<!-- Option 2: the same data as a Base64 string -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...">

Round 1: size — the file wins

This one is clear-cut. Base64 doesn't compress data, it only rewrites it as text, and because of the "3 bytes → 4 characters" scheme the string ends up about 33% bigger than the original file. A 9 KB image as Base64 takes up roughly 12 KB.

So on raw weight the separate file is always lighter. And the larger the image, the more noticeable that difference becomes in absolute kilobytes.

It's worth busting a common myth here: "but the server compresses Base64 on the way out, so there's no difference." Compression does claw back part of the bloat, but not all of it — the squeezed-down text is still heavier than the squeezed-down file, and the browser has to do extra work unpacking it on top. So treating Base64 as "free" is a mistake.

Round 2: request count — Base64 wins

Here Base64 has its single but important trump card. A separate file requires a separate HTTP request: the browser has to open a connection and fetch the resource. A Base64 image arrives with the HTML or CSS, so there's no extra request at all.

In the early web, on HTTP/1.1, this was decisive: dozens of small files genuinely slowed loading. But modern HTTP/2 and HTTP/3 carry many files over a single connection at almost no overhead — and Base64's advantage here has faded a lot. More on that in "Base64 images on the web."

Round 3: caching — the file wins decisively

This is the deciding round. The browser downloads a separate file once and then serves it from cache — across other pages and on repeat visits. One icon used on 20 pages downloads exactly once.

A Base64 string is baked into the HTML or CSS, so it has no cache of its own: it loads again with the page on every request. The same icon across 20 pages means 20 downloads of identical data. On a site with returning visitors, the file wins by a huge margin.

The summary table

Let's put it all in one place:

What to choose in practice

The takeaway is simple, no fluff:

• Plain file — by default. It's smaller, cacheable and easy to update. It's the right choice for the vast majority of images: photos, banners, illustrations, anything that appears on more than one page.
• Base64 — surgically. For tiny icons up to ~5 KB that must appear instantly; for critical CSS; for logos in HTML emails. Here the saved request and guaranteed appearance outweigh the size growth.

It's not either/or, but two tools for different jobs. We break down exactly which scenarios justify Base64 in "Base64 in CSS and email."

A small real-world example

Say you run an online store. The header logo appears on every page — so its place is a separate file: it caches once and works site-wide. But a tiny checkmark icon in an "Added to cart" button, which must flash instantly the moment you click, is a great candidate for Base64 in CSS: one saved request matters more than an extra kilobyte. Product photos, of course, are always separate files — they're large, cacheable and often reused across the catalog.

See the logic? The decision isn't made "in general," but per image — by its size, how often it shows, and how urgently it's needed on screen.

The reverse direction is Base64 → PNG, and the full list of converters is on the all formats page.