Base64 encoder and decoder
The browser's btoa only eats latin-1 and breaks on the first accent. Here the string goes through UTF-8 before encoding, so 'déjà vu' comes back intact.
How the check works
- 1
Text becomes bytes
UTF-8 encoding first: that is what preserves accents, emoji and ideographs.
- 2
Bytes become base64
Three bytes turn into four characters drawn from a 64-symbol alphabet.
- 3
URL-safe variant if needed
The + and / characters become - and _, and the = padding is dropped.
Base64 is not encryption
It is a reversible encoding with no key: anyone decodes it in a second. It exists to carry bytes through a channel that only accepts text — an email, a URL, a JSON field. Putting a password in it is the same as writing it in the clear.
One more consequence: base64 inflates data by about a third. An image as a data URI therefore weighs more than the original file.
Frequently asked questions
Why do my accents turn into question marks elsewhere?
Because the tool encodes in latin-1 instead of UTF-8. The browser's btoa throws beyond character 255; some implementations work around that by truncating, which destroys accented characters.
What do the = signs at the end mean?
Padding. Base64 works in groups of three bytes; when the last group is incomplete, one or two = signs complete the block. The URL-safe variant drops them and the decoder puts them back.
When should I use the URL-safe variant?
Whenever the string travels in a URL or a filename. The + and / characters have their own meaning there and would be reinterpreted; - and _ pass everywhere. It is the variant used by JWT tokens.
The same check over API
This tool runs in your browser. To run the same check from your code, in bulk or server-side, the API answers in JSON.
Read the documentation