Is there a hard size limit where inlining stops making sense?

No formal limit, but 2 KB is a safe ceiling and 10 KB is where we would stop entirely. Above that the caching loss outweighs the saved request on any page a visitor sees twice.

Does Brotli compression cancel out the 33% penalty?

Only partly. Brotli squeezes the Base64 padding well, but PNG and JPEG data is already compressed, so there is little left. Budget for a real increase of roughly 2 to 10 percent after compression.

Do inline images count toward Largest Contentful Paint?

They can be the LCP element, and that is usually bad news. An inlined hero cannot start downloading until the HTML or CSS containing it has parsed, so it arrives later than a preloaded file would.

Are Base64 images bad for SEO?

They are invisible to image search, which is the real cost. Google Images indexes files at URLs, and a Data URI has no URL to index. For any image you want found, use a real file with a descriptive name.

Should I inline images inside a JavaScript bundle?

Watch your build config before you decide. Webpack and Vite already inline assets below a size threshold automatically, so hand-pasting strings duplicates work and bloats the JS parse cost, which is more expensive than the network transfer.

Does inlining help on a slow mobile connection?

Sometimes, for the very first paint, because you skip a round trip on high-latency networks. It hurts on the second page view, when the visitor re-downloads everything instead of reading it from cache.

Can a service worker cache a Data URI?

Not separately, because there is no request to intercept. The bytes are already inside a document the service worker caches as a whole, so you lose the fine-grained control a normal image gives you.

Is Base64 a security risk?

Not by itself, but it is not protection either. Encoding is trivially reversible, so anyone can recover the image in seconds. The real risk is inlining an untrusted SVG, which can carry embedded JavaScript.

Why do so many tutorials recommend inlining?

Most were written for HTTP/1.1, where six connections per host made every extra request expensive. Multiplexing removed that bottleneck years ago. The advice outlived the problem it solved.

What is the fastest option overall for small icons?

An SVG sprite, usually, or an inline SVG element. Both keep the vector benefits, stay cacheable, and let CSS control the colour. Base64 PNG is the fallback for when the source is genuinely a raster image.

When to Use Base64 Images (And When They Slow Your Site Down)

You read that inlining images makes sites faster. You inline a few. Your stylesheet doubles, first paint slips, and now you are not sure whether you helped or hurt. The advice was written for a web that no longer exists.

Here is the direct answer, with the numbers behind it.

When to Use Base64 Images: The Short Answer

Inline an image when it is under 2 KB, needed for the first paint, and rarely changes. Otherwise host it as a normal file.

That covers nearly every decision. The rest of this explains why the line sits there.

To see the exact penalty on your own file, drop it into our image to Base64 converter — it reports the growth percentage next to the output.

Does Base64 Slow Down a Website?

Yes, for anything but very small images. Three separate costs stack up.

The file gets bigger. Base64 turns three bytes into four characters, a flat 33% increase before any compression.

The browser cannot cache it separately. An inlined image lives inside your HTML or CSS. Change one line of that file and the image downloads again.

It delays rendering when it sits in CSS. Stylesheets are render-blocking. Every visitor waits for the whole file, payload included, before anything appears.

For a 1 KB icon those costs are noise. For a 200 KB illustration they are the difference between a fast page and a slow one.

Base64 vs an Image File: The Honest Comparison

Factor	Inline Base64	Normal image file
Extra HTTP request	None	One, cheap under HTTP/2
File size	About 33% larger	Original size
Browser caching	Tied to the parent file	Cached independently
Reuse across pages	Re-sent every time	Downloaded once
Render blocking	Yes, inside CSS	No
Image search visibility	None	Indexable
CDN optimisation	Not possible	Resize, format, compress

One column wins on a single row. That should tell you how often inlining is the right default.

The Size Increase, Measured

Every Base64 string is about a third larger than the file it came from. The arithmetic is fixed: three bytes in, four characters out.

Original file	As Base64	Extra bytes
1 KB icon	1.33 KB	340 B
10 KB logo	13.3 KB	3.4 KB
100 KB photo	133 KB	34 KB
1 MB hero image	1.33 MB	340 KB

People assume gzip erases this. It does not. Image data is already compressed, so there is almost nothing left to squeeze — expect a real cost of a few percent after Brotli, not zero.

Five Cases Where Inlining Genuinely Wins

Critical icons above the fold. A 500-byte SVG arrow that must appear instantly.
Single-file HTML. Reports and exports that have to work with no network at all.
Generated one-off images. QR codes and charts created for a single page view.
Offline-first apps. Everything ships in the bundle by design.
Loading placeholders. A tiny blurred preview shown while the real image downloads.

Every one is small, immediate, and not worth caching.

Five Cases Where It Backfires

Photographs. Too large, and always better served from a CDN.
Site-wide logos. Cached once as a file; re-sent on every page as Base64.
Anything you want in image search. A Data URI has no URL to index.
Responsive images. Srcset exists to send one size; inlining sends them all.
Email templates. Outlook strips Data URIs and shows a broken box.

That third one costs more than teams expect. If image search sends you traffic, inlining removes the asset from the index entirely.

What the Old Advice Got Wrong

Under HTTP/1.1, browsers opened about six connections per host and queued everything else. Each request carried real overhead, so bundling and inlining were genuine wins.

HTTP/2 multiplexes many requests down one connection. The per-request cost largely went away, and with it most of the case for inlining.

The tutorials never caught up. When you read that inlining is a performance best practice, check the publication date — the recommendation usually predates the protocol that invalidated it.

Wrapping Up

Knowing when to use Base64 images comes down to one question: is this small, urgent, and stable? If yes, inline it. If no, host it.

Measure rather than guess. The PNG to Base64 encoder shows the exact growth for your file, and if you need to read a string back, the Base64 image decoder handles it.

For implementation detail, see our guides on Base64 images in CSS and HTML and converting images to Base64 in JavaScript.