Base64 images, and when they are worth it
Why encoding inflates a file by a third, the cases where inlining still helps, and why it is usually the wrong choice on a modern site.
Last reviewed · 1,283 words
In short
- Base64 encodes three bytes as four characters, so an encoded image is 33% larger than the original.
- Inlining removes an HTTP request, which mattered under HTTP/1.1 and matters far less under HTTP/2 and HTTP/3.
- An inlined image cannot be cached separately, so it is re-downloaded with every change to the page that contains it.
- It is genuinely useful for tiny icons, email templates, and anything that must survive as a single file.
- Base64 is encoding, not encryption. Anyone can decode it instantly.
Base64 represents binary data using 64 printable characters — A to Z, a to z, 0 to 9, plus and slash — so that it can travel through systems that expect text.
Why it is 33% larger
The encoding takes three bytes at a time and represents them as four characters. Three bytes is 24 bits; four base64 characters carry 6 bits each, which is also 24. Every group of three input bytes therefore becomes four output characters.
4 ÷ 3 = 1.333, so the output is 33% larger than the input, always.
Padding with = rounds the length to a multiple of four when the input is not divisible by three, adding one or two characters at most.
A 30 KB image becomes about 40 KB of base64. On a page with ten inlined images, that is 100 KB of pure overhead.
Data URLs
An image is inlined using a data URL:
<img src="data:image/png;base64,iVBORw0KGgoAAAA...">
The parts are the scheme, the MIME type, the encoding marker, and the payload. It works in src attributes, in CSS url(), and anywhere a URL is expected.
SVG is the exception worth knowing: because it is already text, it can be inlined without base64 by URL-encoding it instead, which avoids the 33% penalty entirely. For an SVG icon, URL encoding is strictly better.
When inlining helps
Very small images. Below about 1 to 2 KB, the 33% overhead is smaller than the cost of a separate request. A 500-byte icon becomes 667 bytes inline and saves a round trip.
Email. Email clients block external images by default, so an inlined image displays without the recipient clicking "show images". This is the strongest case for base64 and the one where it is still standard practice.
Single-file deliverables. An HTML report, a dashboard export, an offline document that must work with no accompanying assets.
Avoiding a flash of missing content for something above the fold, though modern preloading handles this better.
Data generated at runtime — a canvas export, a signature capture, an image built in the browser — which has no URL to reference.
When it hurts
Caching is the main cost. A separate image file is cached by the browser and reused across every page that references it. An inlined image is part of the HTML, so it is downloaded again whenever the HTML changes — which for a dynamic page is every request.
A logo inlined into every page of a site is downloaded on every page view. The same logo as a file is downloaded once.
HTML cannot be compressed as well. Gzip and Brotli work on repetition, and base64 of an already-compressed image such as a PNG or JPEG is close to random. It compresses barely at all, while the surrounding markup compresses well — so the base64 dominates the transferred size.
Parsing and rendering are delayed. The browser must parse the entire HTML document before it can render, and a document inflated with base64 payloads takes longer to parse. Images referenced by URL load in parallel and do not block.
HTTP/2 removed the original justification. Under HTTP/1.1, browsers limited themselves to six concurrent connections per host, so each request had a real queueing cost and bundling images into the HTML made sense. HTTP/2 multiplexes many requests over one connection, and HTTP/3 improves on that again. The request overhead that inlining was invented to avoid is largely gone.
Debugging is worse. A 40 KB string in the markup makes the source unreadable, and a broken image is much harder to diagnose.
The rough rule
| Image size | Recommendation |
|---|---|
| Under 1 KB | Inline is reasonable |
| 1–4 KB | Depends; measure |
| Over 4 KB | Use a separate file |
| Any size, for email | Inline |
| Any size, single-file export | Inline |
| SVG | Inline with URL encoding, not base64 |
The general answer for a website in 2026: use separate files, served with long cache headers, in a modern format. The alternatives that used to justify inlining have better solutions now.
Better options for the same problems
Modern formats. WebP is typically 25% to 35% smaller than JPEG at equivalent quality; AVIF is smaller again. Serving the right format does more for page weight than any inlining decision.
Responsive images. srcset and sizes let the browser choose an appropriate resolution, which saves far more than 33%.
Lazy loading. loading="lazy" defers images below the fold, which an inlined image cannot do — it is in the HTML and it downloads regardless.
SVG for icons, inlined as markup rather than as a data URL. It is smaller, it scales, and it can be styled with CSS.
Icon fonts and sprite sheets are the older solutions and are largely superseded by SVG.
A CDN with long cache headers, which makes the second and every subsequent request nearly free.
Base64 is not encryption
This is worth stating plainly because it is a recurring misunderstanding.
Base64 is a reversible encoding with no key. Anyone can decode it in one line of code or by pasting it into a web page. It provides no confidentiality whatsoever.
Base64-encoded credentials in a configuration file, an API key encoded in a JavaScript bundle, or a token encoded in a URL are all fully exposed. The encoding hides them from casual reading and from nobody who is looking.
Where the data is genuinely secret, it needs encryption with a key that is not alongside it. Base64 has one job — making binary safe to transmit as text — and it does that job well.
The URL-safe variant
Standard base64 uses + and /, both of which have meaning in a URL — + means
a space in a query string and / is a path separator. Encoded data containing
either breaks when placed in a URL.
Base64url replaces them with - and _, and usually omits the = padding.
It is the variant used in JSON Web Tokens, in URL parameters, and in filenames.
The two are not interchangeable. Decoding base64url with a standard decoder produces garbage or an error, which is a routine source of confusion when a token is copied from one context to another.
Converting between them is a character substitution and re-adding the padding, which is why most libraries offer both as options on the same function.
Where base64 is used besides images
The encoding predates the web and appears wherever binary has to travel through a text channel.
Email attachments. MIME encodes every attachment in base64, which is why an email with a 3 MB photograph transfers about 4 MB.
Basic HTTP authentication. The username and password are joined with a colon and base64 encoded — which, to repeat the point above, is encoding rather than protection. Over plain HTTP the credentials are effectively in the clear.
JSON Web Tokens. Each of the three parts is base64url encoded. The payload is readable by anyone holding the token; the signature is what makes it trustworthy, not the encoding.
Embedded fonts and certificates. A PEM certificate is base64 with header and footer lines.
Binary in JSON. JSON has no binary type, so a file transmitted inside a JSON payload is base64 encoded, with the 33% cost.
In every one of these the reason is the same: the channel expects text, the data is binary, and base64 is the standard bridge between them.
What this tool assumes
- Standard base64 encoding per RFC 4648, with padding, producing output 33% larger than the input.
- The data URL includes the MIME type detected from the file, which browsers require to render the image correctly.
- Conversion happens entirely in your browser. The image is never uploaded anywhere.
- Very large files will produce very large strings and may be slow to handle in an editor.
- For a website, a separate file with cache headers is almost always the better choice.