Base64 Encoder And Decoder For Text, Files And Images

Base64 rewrites arbitrary bytes using only 64 safe characters - A-Z, a-z, 0-9, + and / - so they survive a journey through something that was only ever designed to carry text: an email header, a JSON field, a database column, a URL, or the src attribute of an <img>. It is an encoding, not encryption. Anybody can decode it in a second, so it hides nothing. Because four characters stand in for every three bytes, the result is always about a third larger than what went in.

Who ends up here

Usually somebody who is not a developer and has been handed an instruction. A theme wants a logo “as a data URL”. An API returns a document as one long string that has to be turned back into a PDF. A no-code tool refuses a file upload but accepts a pasted data: value. An email signature has to travel as a single block of HTML with the picture inside it. All four of those are a Base64 encode or decode, and all four are handled by the three tabs above.

Why we rewrote the encoder instead of using the browser's

Most pages offering to base64 encode text call the browser's built-in btoa(). That function maps one character to one byte, so anything above U+00FF - an emoji, a Chinese character, a curly quote, even a plain é - makes it throw an error. That is why so many of these tools die on the first accent in a French name. This one converts your text to UTF-8 bytes first and encodes the bytes, then reverses exactly that on the way back, so emoji, accented Latin, Chinese, Arabic and an empty string all come out the way they went in.

The second common bug is size. The usual shortcut for files, String.fromCharCode(...bytes), passes every byte as a separate function argument and overflows the call stack somewhere around a couple of hundred kilobytes, which is why a lot of encoders quietly fail on a real photo. This one walks the file three bytes at a time and never spreads anything, so the only real limit is your device's memory. We cap uploads at 25 MB, and the read-only boxes show the first 60,000 characters of a very long result while Copy still hands over every character.

Decoding is deliberately forgiving

Real Base64 rarely arrives clean. It comes wrapped in a data: URL, inside a CSS url(), in quotes from a JSON file, split across lines by an email client, percent-escaped from a query string, in the URL-safe alphabet that uses - and _, or with the = padding stripped off. The decoder accepts all of that, tells you what it had to fix, and shows a plain-English message instead of throwing when the input genuinely is not Base64. If the data turns out not to be text at all it says so and names the format it recognised, rather than filling the pane with replacement characters.

What it does not do

• Base64 is not compression. Everything gets bigger, never smaller.
• Base64 is not security. Treat an encoded password exactly as you would treat a plain one.
• A data URL is the wrong answer for a large image. It cannot be cached separately from the page it sits in, so it is re-downloaded on every visit. Inline icons, link to photos - and if a photo is too heavy, the image to WebP converter will shrink it first.
• Everything runs in your browser. Nothing is uploaded, so nothing is stored, and it works offline once the page has loaded.

When the result needs to be a page

Sometimes the point of encoding an image is to send it to someone, and a wall of Base64 in a chat message is not that. The Publish button turns your result into a real web page on a free HTTPS link - for an image, a page that displays the picture straight from its data URL, with the snippets underneath. No account is needed, the link lasts 30 minutes unless you claim it, and claiming it is free. If you also need to escape that markup for a page, the HTML encoder is next door, and how publishing works explains the rest.