Convert an Image to Base64
Encodes an image as a Base64 data URI you can paste straight into CSS, HTML, or Markdown, with the snippet formatted for each. It also shows exactly how much larger the encoded version is, because the single most common mistake with this technique is inlining something far too big and turning a cacheable image into uncacheable text.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Data URI, CSS, HTML, and Markdown output
- Live preview decoded from the result
- Size comparison with a warning above 8 KB
- Format detected from the file's bytes
- Encoding happens locally in the browser
How to use Image to Base64
- 1
Drop in an image
Any format works. The MIME type is read from the file's own bytes rather than its extension, so a mislabeled file still produces a correct data URI.
- 2
Pick the output format
Choose the plain data URI or a ready-made CSS, HTML, or Markdown snippet.
- 3
Check the size figures
Compare the original and encoded sizes. If a warning appears, the image is probably too large to be worth inlining.
- 4
Copy and paste
Copy the result into your stylesheet, template, or document.
How it works
The file is read as raw bytes. Those bytes are converted to Base64 in chunks of 32 kilobytes, and the result is prefixed with the MIME type to form a data URI.
The chunking is not an optimization — it is a correctness fix. The obvious way to
turn bytes into a string is to spread the array into String.fromCharCode, which
works perfectly on a small icon and crashes on anything large, because every byte
becomes a separate function argument and the call stack has a limit somewhere
around a hundred thousand of them. The failure appears only once a real user
tries a real photograph, which is a bad time to discover it.
The MIME type comes from the file's own signature rather than its extension or
the type the browser reports. A PNG renamed to .jpg would otherwise produce a
data URI declaring image/jpeg around PNG bytes. Browsers are forgiving about
that mismatch and will usually display it anyway, but stricter parsers — email
clients especially — are not.
The preview at the bottom is rendered from the generated data URI rather than from the original file. That makes it a real check: if the preview displays, the string you are about to copy is valid.
Where this is genuinely the right technique
Small CSS background icons. A chevron, a checkmark, a bullet — inlined, they arrive with the stylesheet, cost less than a request, and never flash in late.
Self-contained documents. An HTML file, an email template, or a Markdown document that has to work when moved, emailed, or opened offline, with no accompanying folder of assets.
Build-time embedding. Most bundlers inline assets under a size threshold automatically for exactly this reason, and doing it by hand is the same idea applied to one specific file.
Anywhere external requests are blocked or awkward — some restricted environments, sandboxed previews, and certain content management systems that will accept markup but not file uploads.
Where it is the wrong technique
Photographs and any large image. The 33 percent growth is the smallest of the problems; losing separate caching is the real cost.
Anything reused across pages. Each page carries its own copy of the bytes, and the browser cannot recognize them as the same image.
Anything that changes independently. An inlined logo means editing the stylesheet to change the logo, and invalidating the stylesheet's cache for every visitor when you do.
If you are unsure, the size warning in the tool is a reasonable rule: under 4 KB inline freely, 4 to 8 KB think about it, above 8 KB use a normal image reference.
Examples
A small SVG icon for a CSS background
This is exactly the case inlining is for. At 585 bytes the icon costs less than the HTTP request that would fetch it separately, and it arrives with the stylesheet so there is no second round trip and no flash of a missing icon.
A photograph, which is the case to avoid
640 KB of Base64 text now lives inside the HTML document. It cannot be cached separately, it is re-downloaded on every single page view, it makes the document itself slow to parse, and the browser cannot start decoding it until the whole document has arrived. A normal image tag would be faster in every respect.
Frequently asked questions
Why is the Base64 version larger than the file?
Because Base64 represents every three bytes of binary data as four printable characters, which is a fixed 33 percent increase, plus a few bytes of padding and the data URI prefix. There is no encoder that avoids this — it is inherent to representing arbitrary bytes using only 64 safe characters. Compression at the transport level recovers some of it, but not all.
When is inlining an image actually worth it?
When the image is small enough that the HTTP request costs more than the bytes do — in practice under about 4 KB. Tiny icons, a single-color chevron, a small logo in an email template, or an image that must survive being copied around as one self-contained file. Above 8 KB the benefits have usually reversed.
Does inlining hurt caching?
Yes, and this is the deciding factor for anything non-trivial. A normal image is cached once and reused across every page. An inlined one is part of the document or stylesheet, so it is re-downloaded whenever that file changes, and it can never be cached independently. For an image used on every page of a site, inlining is close to the worst option available.
Can I use this in an email?
Sometimes, and this is one of the genuinely good use cases — but test first. Gmail's web client blocks data URIs in image tags, while several desktop clients accept them. Where they work, inlining removes the "images not displayed" prompt entirely, which is why the technique keeps coming up in email development despite its drawbacks.
Is my image uploaded to check its type?
No. The file is read into the browser tab, the first 64 bytes are examined to identify the format from its signature, and the whole thing is encoded locally. Nothing is transmitted. That matters here more than usual, because people frequently encode unreleased logos and internal assets.
Further reading
- Base64 Adds Exactly a Third, Whatever You Put Into ItBase64 has a reputation for making files bigger, and people are vague about by how much. It is exactly a third, every time, for every kind of data — and the reason it is exact is more useful to know than the number.
- Compressed, Base64 Cost Nothing on a JPEG and 17% on JSONBase64 costs a third, and almost everything it travels over is compressed, so the real question is what survives the compressor. The answer is not one number: on already-compressed data the overhead vanishes, and on compressible data a sixth of it stays.
- Hex Is Twice the Size of Your Data, Base64 Is a Third MoreHex and base64 solve the same problem — get binary through a channel that only carries text — and one of them costs six times as much as the other. Hex still turns up constantly, and usually for a reason that has nothing to do with size.