What Base64 actually is (and isn't)
Base64 maps every 3 bytes to 4 characters from a 64-symbol alphabet (A–Z, a–z, 0–9, +, /), padding with =. It exists so binary data can travel through text-only channels — email attachments, JSON payloads, data: URLs, JWT segments. It is encoding, not encryption: anyone can decode it instantly, so it hides nothing and secures nothing.
The Unicode trap
The browser's raw btoa() throws on any character outside Latin-1 — the classic "InvalidCharacterError" on emoji. The fix (used here) is encoding the string to UTF-8 bytes first, then Base64-ing those bytes; decoding reverses it. If you've ever decoded Base64 and gotten mojibake like ä½ å¥½, the encoder skipped that step.
Frequently asked questions
Is Base64 encryption?
No — it's a reversible re-spelling of bytes with zero secrecy. Anything Base64-encoded is effectively plaintext; for secrecy you need actual encryption (AES, age, etc.).
Why is Base64 output longer than the input?
Every 3 bytes become 4 characters, so encoded data is ~33% bigger (plus padding). That overhead is the price of surviving text-only channels.
What are the = signs at the end?
Padding. Base64 works in 3-byte groups; when input length isn't divisible by 3, one or two = characters pad the final group. Some variants (JWTs use base64url) drop them.
Can this decode Base64 images or files?
It decodes to text (UTF-8). For images, take the Base64 into a data: URL — data:image/png;base64,YOUR_STRING — and open it in a browser tab to view the file.