Image ↔ Base64 Converter
Turn an image into a data URI, or turn a data URI back into an image. The size overhead is reported exactly, so you can decide whether embedding makes sense.
Drop an image here, or choose one. It is read with the File API and never leaves this page.
A data URI is the image, not a link to it
A data URI embeds the bytes of a file directly inside a URL:
data:image/png;base64,iVBORw0…. The browser does not fetch anything —
it decodes the Base64 in place and treats the result as the resource. That is why a data
URI works offline, works from a file:// page, and keeps working after the
original file is deleted.
It is also why data URIs are bigger. Base64 encodes three bytes into four characters, so
the payload grows by about 33% before you add the
data:image/png;base64, prefix. This tool reports the exact overhead for your
file so you can decide whether embedding is worth it.
| Original size | Base64 size | Overhead |
|---|---|---|
| 3 bytes | 4 characters | +33.3% |
| 1 KB | ≈ 1.37 KB | +365 bytes |
| 100 KB | ≈ 136.7 KB | +36.7 KB |
When embedding is the right call
The trade-off is one request versus a bigger document. Embedding wins when the image is small and the request overhead dominates, and loses when the image is large and blocks something more important.
- Good fit: icons, inline SVG fallbacks, a placeholder shown before the real image loads, tiny tracking pixels, and anything that must render in an email client — many mail clients refuse to load remote images by default, and a data URI is the only thing guaranteed to appear.
- Bad fit: photographs, hero images, and anything above roughly 2 KB. An embedded image cannot be cached separately, cannot be progressively loaded, and sits in the critical path of the document that contains it.
An embedded image is not private in the way people assume. A data URI is not a fingerprint, an access control, or a signed URL — it is the file. Anyone who can read the HTML can decode it back to the original bytes and use it however they like. If you need the image protected, serve it from somewhere that enforces authorization. Embedding is a delivery decision, not a security one.
Why other converters mangle the output
Two failure modes are common. The first is treating the file as text:
btoa(fileString) throws on most binaries, and when it does not it produces
something that decodes to garbage. The correct route is to read the file into a byte
buffer and encode that. The second is chunking: naive
String.fromCharCode.apply over a large array blows the call stack on files
above roughly 100 KB. This tool walks the buffer in blocks so a multi-megabyte image
encodes without incident.
Frequently asked questions
Why is my base64 so long?
Because it contains the entire image. A 200 KB photo becomes roughly 267 KB of text. If the length is a problem, the image is too large to embed.
Can I use a data URI in CSS?
Yes: background-image: url("data:image/png;base64,…"). Remember to URL-encode characters if the value is not quoted, and keep in mind that the rule is parsed as part of your stylesheet, so it blocks style computation.
Is there a size limit?
Browsers impose limits on URL length, and some older ones cap data URIs at around 2 MB in certain contexts. Practical guidance: keep embedded images under a few kilobytes.
Does the image get uploaded?
No. The file is read through the File API into memory in this tab, encoded locally, and displayed locally. There is no network request to make.
Privacy. Encoding happens entirely on your device. If you are converting a screenshot that contains customer data, an internal dashboard or an unreleased design, it still never leaves your machine.