What Base64 is actually for
Base64 exists to move binary data through channels that only reliably carry text. Email bodies, JSON string fields, XML documents, HTML data URLs and HTTP headers all expect text, and raw bytes passing through them get corrupted by encoding conversions, line-ending translation or control-character handling.
Encoding three bytes as four printable characters sidesteps all of that at a cost of roughly 33% size. That trade is worth it when the alternative is corruption, and pointless otherwise — encoding something that was already text, purely because it looks technical, is a surprisingly common piece of cargo-cult engineering.
The most visible everyday use is the data URL: an image encoded directly into a stylesheet or HTML document, avoiding a separate network request for something small.
Base64 is not encryption, and the confusion is dangerous
This needs stating plainly because it appears in production systems with real consequences. Base64 is reversible by anyone, with no key and no secret involved. A password stored as Base64 is stored in plain text with a step that filters out only the incurious.
The confusion arises because encoded text looks scrambled, and looking scrambled is what most people associate with being protected. It is worth internalising the distinction: encoding changes representation, encryption changes access. Only one of them requires a key.
If you find Base64 used as protection in a codebase, treat it as a finding rather than a style preference. The data it was protecting should be considered exposed.
URL-safe encoding, and why JWTs need it
Standard Base64 uses plus and forward slash for its last two characters, and equals for padding. All three carry meaning in a URL: plus is a space in a query string, forward slash is a path separator, and equals separates a parameter from its value. A standard Base64 string dropped into a URL therefore arrives corrupted.
URL-safe Base64 substitutes hyphen and underscore and omits the padding. JWTs use this variant for all three segments, which is why a JWT segment pasted into a standard decoder sometimes fails with a padding error.
When decoding, it is worth accepting both forms rather than making the user work out which they have — this page does, restoring the padding and translating the characters automatically.
Why non-ASCII text breaks so many Base64 tools
The browser's built-in encoding function handles only characters up to U+00FF and throws on anything above it. Tools that call it directly therefore fail on Hindi, Chinese, Arabic, Japanese, emoji, and even on curly quotes pasted from a word processor.
The correct approach is to encode the text to UTF-8 bytes first and then Base64 those bytes, which is what this page does. Decoding reverses it, interpreting the decoded bytes as UTF-8 rather than as individual characters.
It is worth testing any encoding tool you rely on with a non-ASCII string before trusting it with real data. Silent corruption of names and addresses is a genuinely common bug in systems that assumed English.