Should You Use Base64 Images? Usually Only the Tiny Ones

For anything larger than an icon, no. Inlining an image as a Base64 data URI saves you one network request and costs you 33% more bytes, separate caching, lazy loading and format negotiation. Under about a kilobyte that trade is fine — a bullet icon, a background pattern, a spinner. Above a few kilobytes, the request you avoided was far cheaper than everything you gave up for it.

How much bigger does Base64 make an image?

A third bigger, near enough. Base64 spends four characters on every three bytes, so the increase is a fixed 33%, plus the data:image/png;base64, prefix and up to two = characters of padding. A 12 KB PNG becomes roughly 16 KB of text. That is arithmetic, not a weakness in some encoder, and no tool is going to beat it. What Base64 actually is has the bit-level version if you want it.

Compression over the wire gives some of it back. Gzip and Brotli find a little redundancy in a Base64 string, so the transferred size is not the full 133%. But it is never back to the original either, and for a PNG, JPEG or WebP the underlying bytes were already compressed, which means there was nothing much left to squeeze in the first place. Budget for the overhead rather than assuming the transfer encoding erases it.

What do you lose by inlining an image?

An image with its own URL is downloaded once and reused everywhere. Give it a hashed filename and a long cache header and a returning visitor never fetches it again, on any page.

The same image inlined into a stylesheet is now part of that stylesheet. Change an unrelated colour, ship a new hash, and every visitor re-downloads the image along with it. Inline it into the HTML instead and it comes down on every single page view, because HTML is normally not cached at all.

The rest goes with it:

• No lazy loading. loading="lazy" does nothing for bytes that are already in the document. An inlined image below the fold is paid for in full, immediately.
• No format negotiation. A <picture> element serves AVIF or WebP to browsers that support them and something older to the rest. A data URI is one fixed encoding for everybody.
• No responsive sizes. srcset is a comma-separated list and a data URI contains a comma, so the two do not mix. The phone downloads whatever the desktop needed.
• It blocks the first paint. A data URI in CSS is parsed before anything renders. A 200 KB photo inlined into a stylesheet delays the first pixel on every page that loads that stylesheet.
• It wrecks your diffs. One line of twenty thousand characters changes whenever the image does, and nobody reviews that line.

Does inlining still save time on HTTP/2?

Much less than it used to. The classic argument was request count: under HTTP/1.1 a browser kept around six connections open per host and everything else waited in line, which is why sprite sheets and data URIs were standard advice. HTTP/2, standardised in 2015 and supported by every current browser, multiplexes many requests over one connection. An extra small file is not free — it still carries its own headers and work on the server — but it no longer blocks anything else.

What survives is latency on the very first load. A request still needs a round trip, and on a slow mobile connection that is measurable. This is why the remaining honest use of inlining is tiny assets needed in the first paint — not photographs, not hero images, not anything you would call content.

When is inlining still the right call?

• Assets under a kilobyte or two that appear on most pages: a chevron, a checkbox tick, a repeating background, a loading spinner.
• A file that has to work with no hosting attached. A single-file HTML report you email as an attachment, a bookmarklet, a self-contained demo someone will open from their desktop. There is no server to fetch an image from, so the image has to be in the file.
• An offline page. Whatever your service worker shows when the network is gone cannot depend on a fetch.
• Anywhere binary is not allowed. JSON has no binary type, so an image travelling inside an API payload or a config file has to be Base64. The cost is that the file becomes one enormous unreadable line.

Notice what is not on that list: photographs, logos above a couple of kilobytes, anything that appears on one page only, and anything a user uploads.

What size is too big to inline?

Encode the file and look at how long the string is. That is the entire decision. Dropping the image into the data URI converter here puts the original bytes, the encoded bytes and the overhead side by side — the encoded figure counts the whole string, prefix included, so it lands a little above 33% rather than exactly on it. It warns you outright once the string passes 100 KB, but treat that as the point where inlining is indefensible, not the point where it stops being sensible. The table is the judgement the tool does not make for you. Nothing is uploaded, which matters more than usual here: a data URI is a complete copy of the file in plain text.

If the number surprises you, the image is the problem and not the encoding. A 90 KB icon is not an icon. Resizing and compressing it before you encode anything often answers the question by itself, and where image weight actually comes from explains why the dimensions matter more than the quality slider.

Should you Base64 encode an SVG?

No, and it is the one case where the answer has nothing to do with size thresholds.

An SVG is already text. Base64 encoding it adds a third to the size for no benefit and turns something readable into noise. Percent-encoding only the characters that would break a CSS url() — #, <, >, quotes — keeps it shorter, keeps it legible in the stylesheet, and compresses far better, because gzip finds repetition in XML and finds almost none in Base64. The converter linked above switches to percent-encoding automatically when you give it an SVG, and tells you that is what it did.

For an icon inside HTML, better still: paste the <svg> element itself rather than any kind of URI. Then currentColor works, CSS can style the paths, and there is no encoding overhead at all.

What breaks when you use a data URI?

• Email. Gmail and several other clients refuse to render an image from a data URI, so the recipient sees a broken box. If the destination is an inbox, host the image and use a normal URL.
• Content Security Policy. A policy of img-src 'self' blocks data URIs outright. The directive needs data: added explicitly, and plenty of security teams will not sign off on that, because it widens what a script injection can render.
• Image search. An inlined image has no URL, so there is nothing for a crawler to fetch or index. If you want the image itself to be findable, it needs to be a file.

Should your bundler decide instead of you?

Pasting data URIs into source by hand is how a repository ends up with unreviewable files and images nobody can find to update. Keep the image as a normal file and let the bundler inline it below a size threshold: Vite inlines assets under 4,096 bytes by default, and webpack's asset modules work the same way with a similar few-kilobyte cutoff. Both let you change the number or force either behaviour per file.

You keep readable source, you still get the small-file optimisation, and there is one number to change when the icon turns into a photograph. A pasted string gives you none of that. It is also the version that stays in the repository for years, because nobody can tell what it is or where it came from.

Last updated September 19, 2026