Base64 is not encryption. It's an encoding. It offers no secrecy, no protection, and no security whatsoever — anyone who sees Base64 text can decode it back to the original in about two seconds, with no key, no password, and no special knowledge.

This trips people up often enough to be worth spelling out properly, because treating Base64 as if it protected something is a genuine security mistake — and one that has put real credentials into the wrong hands.

What Base64 actually does

Base64 converts data into a limited set of safe, printable characters — letters, digits, and a couple of symbols. That's it. Its entire purpose is transport: some systems were built to handle plain text and will mangle or reject anything unusual, so Base64 rewrites awkward data into a form that survives the journey intact.

That's why it shows up in email attachments, in data URIs that embed a small image directly in HTML or CSS, in JSON Web Tokens, and anywhere binary data needs to travel inside a text-only channel.

Notice what's missing from that list: any mention of secrecy. Base64 was never designed to conceal anything, and it doesn't.

Why people think it's encryption

Because it looks like it. SGVsbG8gd29ybGQ= is not readable at a glance, and unreadable-looking text pattern-matches to "scrambled, therefore protected."

But encryption and encoding are answering completely different questions:

  • Encoding asks: can this data travel safely through this channel? It's reversible by anyone, by design.
  • Encryption asks: can this data be kept secret from anyone without the key? It's reversible only by someone holding that key.

Base64 is reversible by everyone. That's not a weakness in Base64 — it's the entire point of it. It's only a problem when someone mistakes it for the other thing.

The mistake this leads to

The classic error is Base64-encoding a password, an API key, or a token and treating it as safe to store or transmit. It isn't. It's the exact equivalent of writing the secret down in plain sight, just in a font that takes a moment longer to read.

The related trap is the JSON Web Token. A JWT's payload is Base64-encoded, which means anyone holding the token can read everything inside it. The token's signature stops it being forged — but it does nothing to hide the contents. Never put anything confidential in a JWT payload on the assumption that the encoding conceals it.

What to use instead

If you need secrecy, you need real encryption — a proper algorithm with a key that only the intended parties hold. That's a different tool for a different job, and there's no shortcut to it.

If you need to verify data hasn't changed, you want a hash — a one-way fingerprint. Hashes can't be reversed at all, which is what makes them useful for checksums and integrity checks. (A hash isn't encryption either, but for the opposite reason: you can't get the original back even if you want to.)

If you just need data to survive a text-only channel, Base64 is exactly right, and you should use it without worry — just don't ask it to do a job it was never built for.

See it for yourself

The fastest way to internalise this is to watch how trivially it reverses. Encode something in the Base64 tool, then decode it straight back. No key, no password, nothing withheld. That's the whole point — and the whole reason it protects nothing.