Base64 Encoder & Decoder

Common questions

Why do some base64 tools break on accented characters?

Because they use the browser's built-in btoa(), which only understands characters up to code point 255. btoa("café") throws an error outright and anything in Japanese or an emoji is impossible. This tool encodes text to UTF-8 bytes first, so any character you can type survives the round trip intact.

How does it know whether to encode or decode?

It decodes what you paste and checks whether the result is sensible text. Guessing from the characters alone does not work. “Hello123” has the mixed case and digits that look like base64, and “Zm9vYmFy” looks like a word. Actually decoding is a much stronger signal, so you never have to choose a direction.

What is URL-safe base64?

Standard base64 uses + and /, which have meanings inside a URL and get mangled when passed as a query parameter or a filename. The URL-safe alphabet from RFC 4648 uses - and _ instead. JSON Web Tokens use it. Decoding here accepts either without being told which.

Why is base64 bigger than the original?

It encodes three bytes as four characters, so everything grows by almost exactly a third. That is the cost of making binary data safe to put in text, and it is why embedding a large image as a data URI is usually worse than linking to the file.

Do I need the padding characters at the end?

The = characters pad the output to a multiple of four. Some contexts require them and some, including JWTs, drop them. Both are produced and both are accepted on the way in.

Is my data uploaded?

No. Encoding and decoding are arithmetic that runs in your browser, including for files you drop in. Nothing leaves your machine, there is no size limit imposed, and the page keeps working offline.