Image to Base64: When Data URIs Help and When They Hurt
What Base64 image encoding is, how data URIs work in HTML and CSS, and the size trade-off you should know before inlining.
The first time I saw a 40-kilobyte string of gibberish where a src attribute should be, I assumed something was broken. It wasn’t. That gibberish was the image — the whole PNG, encoded as text and stuffed straight into the HTML. That’s a Base64 data URI, and the Image to Base64 tool spits one out from any image you drop on it.
Whether you should use one is the more interesting question.
What Base64 actually does
Base64 takes binary data and rewrites it using 64 safe text characters — letters, digits, + and /. It exists because a lot of the web was built to move text, not raw bytes. Encode a PNG this way and you can paste it anywhere text is allowed: an HTML attribute, a CSS rule, a JSON blob.
The catch is baked into the math. Every 3 bytes become 4 characters, so the encoded version runs about 33% bigger than the file it came from. A 6 KB icon lands around 8 KB as a data URI. Our converter shows you the exact overhead for your image, which is the number that should drive your decision.
The format itself is old — data URIs were specified back in 1998 in RFC 2397. This is not new territory. It’s just easy to misuse.
Where it earns its keep
Inlining an image makes sense when the image is small and the extra request costs more than the extra bytes.
- Tiny icons and UI bits. A 400-byte magnifying-glass SVG inlined into CSS saves a round trip and never flashes in late.
- Email. Some clients strip linked images or hide them behind a “load remote content” wall. An inline data URI in an
<img>tag sidesteps that in many web clients. - Single-file deliverables. An HTML report you email around, or a self-contained widget, works offline when the images live inside the file.
- Loading spinners and placeholders. Anything that must appear before the network settles.
Where it hurts
I’ve watched people inline a hero photo and wonder why the page felt sluggish. Here’s the thing to remember: a data URI is part of the document, so it can’t be cached on its own.
- No separate caching. A linked image is downloaded once and reused across pages. An inlined one is re-downloaded with every page that embeds it.
- Bloated source. Big data URIs make your HTML or CSS huge and painful to read or diff.
- Slower first paint. The browser has to parse the whole blob before it finishes the document. A linked image loads in parallel instead.
- HTTP/2 changed the math. The old reason to inline was to cut requests. With multiplexing, many small requests are cheap now, so that argument mostly evaporated.
My rough rule: under a couple of kilobytes and used in one place, inlining is fine. Bigger than that, or reused anywhere, link it as a normal file.
Using the output
Drop an image in and the tool gives you four ready-to-paste versions:
- the raw data URI
- an
<img>tag with thesrcfilled in - a CSS
background-imagerule - Markdown image syntax
One email warning worth repeating: Outlook renders with Word’s engine and blocks data URIs in CSS backgrounds outright. Inline <img> data URIs fare better in clients like Apple Mail, but email is a minefield, so test in the ones your readers actually use.
It all happens in your browser through the FileReader API. The image never leaves your machine, which matters when you’re encoding an unreleased logo or a client’s screenshot.
Drop an image into the Image to Base64 tool and copy the exact snippet you need.