Base64 Encoder & Decoder

Base64 exists because a lot of infrastructure built around text — email, JSON, XML, URLs — cannot reliably carry arbitrary binary bytes, which might contain control characters, null bytes, or byte sequences that terminate a string early or break a parser outright. Base64 maps every three bytes of arbitrary binary data onto four characters drawn from a fixed set of 64 that every text-based system handles safely — letters, digits, and two symbols — so the encoded result can be embedded inside JSON, sent as an email attachment, or included in a document without anything downstream misinterpreting it as something other than plain text.

The overhead of that safety is fixed and unavoidable: four output characters for every three input bytes, an expansion of roughly 33%, regardless of what the underlying data actually is. That is the price paid for guaranteed safe passage through text-only channels, not a flaw specific to any particular implementation.

The browser's built-in `btoa` function, which many quick Base64 implementations reach for directly, throws an error the moment it encounters any character above code point U+00FF — which includes essentially all emoji, Chinese, Japanese, Korean, Cyrillic, Greek and Arabic text, plus a fair number of accented Latin characters used in French, German, Spanish and elsewhere. This is not an obscure edge case affecting rare input; it affects a very large fraction of real-world text, and its is why so many hand-rolled Base64 tools work perfectly in testing with plain English input and then fail the first time a user pastes something with an emoji or a non-Latin name in it.

The fix is encoding the text as UTF-8 bytes first, then Base64-encoding those bytes — which is what correctly built encoders do and what this tool does — rather than trying to feed Unicode code points directly into an encoding designed for byte sequences below 256.

Standard Base64's character set includes `+` and `/`, both of which are meaningful in a URL — `+` is sometimes interpreted as a space, and `/` is a path separator — so a standard Base64 string pasted directly into a query string or a file name can silently corrupt or truncate on the way through whatever is parsing that URL. Base64URL replaces those two characters with `-` and `_`, neither of which carries special meaning in a URL, and typically also drops the trailing `=` padding characters, which exist purely to signal length and are unnecessary once the decoder already knows to expect them.

JSON Web Tokens use Base64URL for exactly this reason: a JWT is designed to travel inside an HTTP Authorization header and sometimes a URL, and standard Base64's reserved characters would make that unreliable.

It is worth stating plainly because the assumption comes up often: Base64 provides zero confidentiality. There is no secret key involved anywhere in the process, so anyone who obtains a Base64 string can decode it back to the original data in an instant using nothing more than a standard library call or a tool exactly like this one. Encoding a password or an API key in Base64 before storing or transmitting it provides no protection whatsoever — it only obscures the value from a casual glance, which is a very different property from actual security.