Why Unicode breaks naive Base64 tools
JavaScript's built-in btoa operates on Latin-1 and throws on any character above U+00FF. That means the obvious implementation of a Base64 tool fails on the first accented letter, Cyrillic character, CJK character or emoji it meets.
The fix is to encode the text to UTF-8 bytes first and Base64 those bytes. That is what this tool does, which is why "café 👋" round-trips correctly here and errors on many other converters.
Base64 is encoding, not encryption
This is worth stating plainly because the mistake is common and consequential. Base64 is a reversible representation with no key and no secret — anyone can decode it instantly. It provides no confidentiality whatsoever. Its purpose is to carry binary data through channels that only handle text safely.
URL-safe Base64
Standard Base64 uses + and /, both of which have meaning in a URL, and = padding, which can be mangled. The URL-safe variant substitutes - and _ and drops the padding. JSON Web Tokens use this variant, which is why a JWT segment pasted into a standard decoder often fails. The decoder here accepts both.
Size cost
Base64 encodes three bytes as four characters, so encoded data is about 33% larger than the original. That is the trade for text-safety, and it is why embedding large images as data URIs makes pages heavier than linking to the file.