Image to Base64

Base64: what it is, and the 33% tax nobody mentions

A data URI is a way of putting a file inside a document instead of linking to it. The syntax is short: data:image/png;base64, followed by the file's bytes translated into Base64.

The 33% is not a rounding error

Base64 represents 3 bytes of binary data using 4 ASCII characters. That is a fixed, unavoidable 33% size increase before any other consideration. A 100 KB JPEG becomes roughly 137 KB of text.

Compare that to what actually happens on the network: your server is almost certainly already serving images with gzip or Brotli, but Base64 text compresses far worse than the equivalent well-chosen binary format. A modern image format is already entropy-coded; re-encoding it as text and then compressing the text recovers much less than people assume.

So the honest framing is: Base64 costs you about a third in raw size, and you are paying it to buy something else. Make sure the thing you are buying is worth it.

When it genuinely is worth it

• Eliminating a request for a critical tiny asset. An above-the-fold SVG sprite or a 1 KB logo, inlined, removes a round trip. On high-latency mobile connections a round trip can cost more than 300 bytes ever will.
• Single-file delivery. Email templates, offline HTML documents, a self-contained demo you want to hand over as one file, a QR-code-encoded page. If there is no server, there is nothing to link to.
• CSS-generated decoration. Small background textures and icon glyphs inside a stylesheet, where a URL would otherwise be resolved relative to the stylesheet's location and cause a surprising 404.

When it is a mistake

• Anything above a few kilobytes. The payload is now inside your HTML, which means it is re-downloaded on every page that includes it, it cannot be cached independently, and — critically — it blocks. Browsers discover inlined images only after parsing the markup; they discover <img src> during preload scanning. Large inline assets delay that discovery.
• Photographs, full stop. Run them through a proper encoder first. If you are reaching for Base64 on a photo, the underlying problem is usually that the photo is unoptimised, not that it is external.
• Anything you hope to cache. An inlined asset lives and dies with the document. Change one word on the page and the user re-downloads every inlined image with it.

Where people get confused

Base64 is not compression. This is the most common misconception by a wide margin. "I base64'd my images to make them smaller" is never true — the output is always larger than the input. If you want smaller, you want a better encoder (WebP or AVIF) or a smaller dimension, not a different text encoding.

Data URIs are not private. Every character is plainly visible in the page source. Obscurity is not encryption; if an image is sensitive, Base64 gives you no protection at all.

Not every data URI is Base64. data:image/svg+xml, followed by URL-encoded SVG is a real and often better option — SVG is already text, so percent-encoding it is dramatically more efficient than Base64-encoding it, and the result stays human-readable and gzip-friendly.

A rule of thumb that survives contact with reality

Inline when the asset is small enough that the request overhead dominates — think single-digit kilobytes — and when it appears on pages where avoiding a round trip actually matters. Keep everything else as a separate, cacheable, properly encoded file. The exact crossover depends on your audience's latency and your cache headers, so treat it as a starting hypothesis and measure rather than a law.