When to use it
For things from a few hundred bytes to a few KB — icons, dividers, loading animations — an external link is actually slower: the browser has to parse the HTML, discover the address, then go through DNS, connection and handshake, and finally fetch an image of a few hundred bytes, of which the image is only a small part and the rest is fixed overhead. As a Data URI the characters arrive together with the HTML, so rendering does not wait on the network again.
It also suits single-file distribution: offline HTML reports, demos sent to others, intranet pages that cannot reach an external CDN — after inlining you never get a page of broken images because one folder was not copied.
Conversely, article illustrations, product images, thumbnails, avatars and logos should not be inlined: they repeat across pages, need their own cache, and need a separate address so image search can index them. One question decides it: will this image be used again somewhere else? If yes, link it externally.
How to choose the settings
- Start with file size: 10 KB is the dividing line: Under 2 KB, inline directly, it costs almost nothing; 2 to 10 KB is acceptable; above 10 KB, link externally. A 10 KB image becomes about 13 KB of text, and all you save is one request, which is not worth it.
- Next, the format: Small PNG icons, single-colour lines and small arrows suit it best; do not inline photographic JPEGs, since one phone photo is 2 to 5 MB and becomes 3 to 7 MB after conversion. At the same dimensions prefer WebP, usually 20%–30% smaller than PNG.
- The prefix must match the original file: A Data URI must be written in the full form data:image/png;base64, with an ASCII comma immediately after it; pasting plain Base64 into src will not display. If the type is wrong the browser usually guesses from the content, but do not rely on it.
- Keep it on one line: Standard Base64 wraps every 76 characters, and that version is only suitable for email; pasted into HTML, CSS or Markdown it breaks. Before copying, make sure your editor has not inserted real line breaks.
- Control the total per page: No single image over 10 KB, no more than 50 KB of inlined images per page in total, and keep the whole uncompressed HTML under 200 KB where possible. Past those lines compression cannot save you and the first screen slows down noticeably.
Compared with other approaches
Inlining saves one request and one round trip only on the first visit, at the cost of making the image part of the HTML or CSS: the browser does not cache it separately, so it is re-downloaded every time the page loads and the text is retransmitted with it. External images have their own cache and 304 checks, so repeat visits cost almost nothing. Under HTTP/2 and HTTP/3 several images already share one connection, so saving requests is worth much less than in the HTTP/1.1 era, and it is only still noticeable on high-latency networks.
Compared with sprite sheets, both save requests. With fewer than five or six icons, inlining is easier and needs no coordinate bookkeeping; beyond that, a sprite sheet or icon font is better because swapping an image does not touch the whole block of text. SVG icons do not actually need Base64: SVG is already text, inlining it directly inherits currentColor and lets CSS recolour it, whereas converting to Base64 throws that advantage away and is only worth it when it has to go into a CSS background-image.
Compared with other online conversion services, the difference is where the file goes: those sites upload the image to a server to encode it, the original lands on someone else's machine, and the page is stuffed with ads; this tool reads the file with the browser (FileReader), the image never leaves this device, it works offline, and images with private content can be dragged in directly. Its weak points should be stated too: it only encodes, it does not compress or resize, so the output size depends entirely on the original; over 2 MB it only warns, it does not block; and it does not decide for you whether to inline or link externally.
Additional Q&A
How is the 1.33× ratio calculated?
Base64 cuts every 3 bytes (24 bits) into four 6-bit groups, each mapping to one of 64 printable characters. 3 bytes become 4 characters, a ratio of 4 divided by 3, about 1.33. When the original length is not a multiple of 3, one or two equals signs are added at the end, so you often see = or == at the tail; it is only padding.
Why does inlining a large image slow down the first screen?
HTML and CSS block rendering: the browser has to finish parsing before it starts painting. A 500 KB image becomes about 670 KB of text packed into the HTML, and the first screen waits that much longer; that text also has to download completely before it can be decoded, unlike an external image, which can display while it downloads. Enabling gzip on the server recovers part of it, but the compressed result is still never smaller than the original binary.
What are the common reasons an image pasted into Markdown or CSS does not display?
Wrap the img src in double quotes for safety, since the character set contains no quotes; CSS url(...) must be quoted because the string contains plus signs, slashes and equals signs; Markdown wraps the address in parentheses, and square brackets and parentheses in the alt text must be escaped, with the whole syntax on one line. Also, many Markdown renderers and CMSs filter data: addresses, so a pasted image breaks.
In which cases should you absolutely not use inlining?
Large images (over 10 KB is worth thinking twice about, and phone photos are out of the question); many images on one page; logos, avatars and covers that need to be reused across pages; images that depend on their own address for image search, which lose it once inlined; and images that people should be able to right-click and save or put in an email, which most mail clients block.