What Base64 actually is (and what it is not)
Base64 isn't encryption and isn't compression — here's what it's really for, why it makes things bigger, the UTF-8 gotcha, and how to encode or decode it safely.
Base64 shows up everywhere — in data URLs, email attachments, JWTs, API payloads — and it's quietly misunderstood about as often as it's used. The single most important thing to know is what it isn't: it is not encryption, and it is not compression. Getting that straight saves you from some genuinely bad decisions.
What it's for
Base64 takes binary data — an image, a PDF, raw bytes — and rewrites it using only 64 safe text characters: A–Z, a–z, 0–9, plus + and /. That's it. The whole point is to move binary data through systems that only understand text.
Email was built for text. URLs are text. JSON is text. So when you need to stuff an image into an email, embed a tiny icon directly inside a CSS file, or send a file inside a JSON field, you Base64-encode it first — turning the raw bytes into a string those text-only channels can carry without mangling.
Why it makes things bigger, not smaller
People sometimes assume encoding shrinks data. The opposite is true: Base64 makes everything about 33% larger. It works by taking every 3 bytes of input and representing them as 4 output characters — so 3 bytes in, 4 characters out, every time.
That's a fine trade when you need text-safety, and a terrible one if you were hoping to save space. If size is your goal, you want compression — which is a completely different thing.
Why it's not security
Because Base64 looks like gibberish, it occasionally gets mistaken for something secret. It isn't. There's no key and no password — anyone can decode it instantly, because the encoding is public and reversible by design. Putting a password in Base64 is exactly as secure as writing it backwards.
If you need actual secrecy, you need encryption (reversible with a key) or hashing (one-way), not encoding. This is the same misconception that bites people with JWTs: the payload of a token is just Base64, readable by anyone who has it.
The one real gotcha: UTF-8
Plain btoa() in a browser breaks on anything outside basic Latin characters — emoji, accented letters, and non-Latin scripts all throw an error or quietly corrupt. The reason is that btoa expects each character to fit in a single byte, and café or 🎉 don't.
Proper Base64 handling encodes the text as UTF-8 first, so multi-byte characters survive the round trip intact. If you've ever had a Base64 tool turn an emoji into garbage, this is exactly why — it skipped the UTF-8 step.
Encoding and decoding it
Primova's Base64 Encoder / Decoder handles both directions and is UTF-8 safe, so it won't choke on special characters. Paste text to encode it, paste a Base64 string to decode it back, and it works on files too when you need a data URL.
It all runs locally in your browser — nothing's uploaded — which is the right default any time the thing you're decoding might contain a token, a key, or private data. Try it on that mystery string you've been staring at: Base64 Encoder / Decoder.