Image to Base64
Drop a file and get its Base64, a data: URI and the two lines you would
actually paste — an img tag and a CSS url().
The file is encoded here, not uploaded.
Drop a file here or click to choose
Images first, but any file works — encoded on your device
The bytes are not a picture a browser can draw, so the img tag and CSS forms are left out — they would only produce a broken image.
Base64 is not compression. It rewrites every three bytes as four text characters, so the text is always about a third larger than the file it came from. It exists to move a file through somewhere that only carries text — a stylesheet, a JSON field, an email body — not to make it smaller.
How it works
- Choose or drop a file. Images are the common case, but any file is accepted.
- Press Encode. The bytes are read, the first of them are checked against a table of file signatures to work out the real media type, and the encoding runs in slices so the page stays responsive on a large file.
-
Switch between the raw Base64, the data URI and the two snippets, copy what you need, or
take the whole string as a
.txtfile.
The encoding itself is plain arithmetic: three bytes become four characters drawn from a
64-symbol alphabet, and one or two = characters pad the last group when the
file length is not a multiple of three. That padding is why a Base64 string almost always
ends in an equals sign or two, and why the output grows by a third rather than by some
amount that depends on the picture.
What the size line is telling you
Every result shows the file size and the length of the text beside each other, with the growth as a percentage. It is there because the single most common reason to be disappointed by a data URI is expecting it to be a saving. It is not one. The trade a data URI actually makes is a bigger document in exchange for one fewer network request, and that trade only pays on small files.
Two things follow from that. Compress an image before encoding it, not after — the Base64 of a 40 KB JPEG is smaller than the Base64 of the 300 KB PNG it came from, by exactly the margin you saved. And keep inline data out of anything you want cached: a CSS file with a 200 KB payload inside it has to be downloaded again in full every time one selector changes.
Where your file goes
Nowhere. The file is read with the browser's own file API and encoded by JavaScript running in this tab. There is no request that carries it anywhere, and no copy of it on any server of ours, because there is no server of ours in the path at all.
What is honest to add: the page itself loads, the fonts load and the ads on it make their own requests, so a network tab here is not silent. The claim worth checking is narrower and more useful — that nothing leaves carrying your file. People paste API keys, certificates and private documents into Base64 tools every day, usually into ones that post the bytes to a backend first. This one has nowhere to post them to.
Frequently asked questions
Does Base64 make the file smaller?
No, and it never has. Base64 spends four text characters on every three bytes, so the string is roughly a third larger than the file. It is a transport format, not a compression format: it exists so a file can travel through somewhere that only carries text. If size is what you are after, compress the image first and encode the smaller file.
Can I encode something that is not an image?
Yes. The encoder reads bytes, so a PDF, a font, a ZIP or anything else goes through unchanged. Only the two markup snippets are held back for non-images, because an img tag around a PDF is a broken tag rather than a useful one. The raw Base64 and the data URI are offered for every file.
Where does the media type in the data URI come from?
From the first bytes of the file. PNG, JPEG, GIF, WebP, BMP, ICO, TIFF, AVIF, HEIC, MP4, PDF, ZIP, gzip and the two web font formats each have a signature at the start, and that is what is read. Only when the bytes match nothing known does it fall back to the type your operating system attached to the file, and then to application/octet-stream.
Why does the text disappear from the box on a big file?
Above a million characters — roughly 750 KB of file — the string is kept out of the text area on purpose. Putting a string into a form control makes the browser lay out the whole of it, and every switch between the four output forms pays that cost again. Measured here in Chromium: a million characters takes 277 ms, two million takes 683 ms, eight million takes 2.3 seconds. The complete string is still there — Copy puts all of it on the clipboard, and the .txt download holds all of it too — it is just not painted into a box that would stall the tab to show it.
How large a file will it take?
Up to 50 MB. That is not a quota, it is where the arithmetic stops being comfortable: a 50 MB file becomes 69,905,068 characters of text, and a browser holds each character as two bytes — around 140 MB of memory for the string alone. A 50 MB file was measured through it and finished. Past that there is no measurement, so the tool declines rather than guessing on your behalf.
I am pasting an API key or a private certificate. Is that safe here?
People do paste secrets into Base64 tools, which is exactly why this one runs where it does. The file is read by your browser and encoded by your browser; no request carries it to a processing server. The page itself, and the ads on it, make ordinary network requests — that is what you will see in a network tab — but none of them contains your file. If the secret is serious, the safer habit is a local command line: base64 on macOS and Linux, certutil on Windows.
Is a data URI a good idea in production?
For small marks, often yes: an inline icon costs no extra request. For anything large it is usually a loss. The base64 payload cannot be cached separately from the file it sits in, it inflates every HTML or CSS response that carries it, and it cannot be served in a modern format to browsers that want one. A few kilobytes is the usual dividing line.