What Base64 is actually for
Base64 exists to move binary data through channels that only reliably carry text. Email attachments, JSON string fields, HTTP headers and XML documents all fall into that category: raw bytes would be mangled, so they are re-expressed using 64 characters that survive intact everywhere.
The cost is size. Base64 encodes three bytes as four characters, so encoded data is roughly 33% larger than the original. That is why embedding a large image as a data URI can make a page slower rather than faster, even though it removes a request.
Base64 is not encryption
Encoding and encryption are different things, and confusing them causes real security incidents. Base64 uses no key and hides nothing - anyone can decode it in one step, which is precisely what this page does. It offers zero confidentiality.
If you find credentials stored as Base64 in a config file, they are stored in plain text with an extra step. The same applies to Basic authentication headers, which are Base64 of username:password and readable by anyone who captures the request.
Unicode, padding and URL-safe variants
Naive Base64 implementations break on non-ASCII characters, producing errors or mojibake on anything with an accent or an emoji. Text here is encoded as UTF-8 first, so every character round-trips exactly.
The trailing equals signs are padding that brings the output to a multiple of four characters. Some decoders require it and some do not. There is also a URL-safe variant that replaces plus and slash with hyphen and underscore, because the standard characters have their own meaning inside a URL - this is the variant JWTs use, which is why a JWT section will not decode in a strict standard decoder.
Frequently asked questions
- Is Base64 encryption?
- No. Base64 is reversible encoding with no key. Anyone can decode it instantly, so it provides no confidentiality whatsoever and must never be used to protect secrets.
- Why does my Base64 string fail to decode?
- Usually missing padding, whitespace or line breaks pasted in with the string, or a URL-safe variant that uses hyphen and underscore instead of plus and slash. JWT sections use the URL-safe variant.
- Does this handle emoji and accented characters?
- Yes. Text is encoded as UTF-8 before Base64, so every Unicode character round-trips correctly rather than producing corrupted output.
- What are the equals signs at the end?
- Padding. Base64 output comes in blocks of four characters, and the equals signs bring the final block up to length. Some decoders require them; some accept input without.
- Is my data uploaded?
- No. Encoding and decoding run entirely in your browser and nothing is transmitted or stored.