Image to base64

How to use it

1. 1

   Drop the image

   Small ones. Icons, logos and simple graphics are what this technique is for.

2. 2

   Read the ledger

   File bytes, base64 characters, the full pasted length and the growth, with the padding arithmetic spelled out underneath.

3. 3

   Check the budget bar

   It measures your string against 8,192 bytes, the size at which build tools switch from inlining a file to emitting it. Over that line, host the file instead.

4. 4

   Pick the wrapper and copy

   Data URI, a CSS rule, an image tag, Markdown, a JSON string or an SVG image element. One button copies whichever is showing.

The arithmetic, shown rather than asserted

Base64 writes every three bytes as four characters and pads the last group out to a multiple of four, so a file of n bytes becomes exactly four times the ceiling of n over three characters. That is a third larger, always, before the data URI prefix. The ledger prints that calculation with your actual numbers in it, including how many padding characters you ended up with, because a rule of thumb you can check is worth more than one you have to trust.

Why the gzipped number matters more

The raw growth of a third is the figure everyone quotes, and it is the wrong one to make a decision on. Your stylesheet is compressed before it crosses the network, and gzip claws most of that overhead back, because base64 output has only 64 distinct characters in it. The tool compresses the string in the browser and shows you what it really costs on the wire against the file served on its own. The remaining argument against inlining is not size, it is caching.

The 8,192 byte line

Build tools have converged on the same threshold. Webpack's asset modules inline anything under 8,192 bytes as a data URI and emit a separate file above it, and other bundlers default to something near it. It is a reasonable line for a hand written stylesheet too, which is why the budget bar measures against it. Under the line, embedding saves a request and costs almost nothing. Over it, you are pushing uncacheable bytes into every page that carries the document.

An SVG does not want base64 at all

An SVG is already text, mostly ASCII, and base64 makes it a third longer for no reason. Escaping only the handful of characters a URL and an attribute cannot carry gives a shorter string that every browser reads, and it stays readable in the source. That variant appears as its own tab as soon as an SVG is loaded, with the character counts side by side so you can see the difference rather than take it on faith.