Base64 is not encryption (encoding, encryption and hashing, untangled)

cGFzc3dvcmQxMjM= looks like a secret. It’s password123, and turning it back takes no key, no password and no particular skill. Any Base64 decoder will do it, including the one on this site.

People still treat strings like that as protected, and it’s an understandable mistake. Encoding, encryption and hashing all spit out unreadable gibberish, so they end up filed in the same mental drawer. What they guarantee could hardly be more different.

Here’s how the three sort out.

Encoding: a change of alphabet

Encoding exists to get data through a channel that would otherwise mangle it. Email headers, URLs, JSON strings, XML: all of them handle text and only text. Push raw binary through one and it comes out corrupted. Base64 rewrites arbitrary bytes using 64 characters everyone agrees are safe (A–Z, a–z, 0–9, +, /). The price is 33% growth, since every 3 bytes become 4 characters.

The property that matters is this: reversing it requires nothing secret. The algorithm is public and takes no parameters, so decoding is purely mechanical. Base64 gives you exactly zero confidentiality. It’s a shipping container, not a safe.

URL encoding (%20 for a space) and HTML entities (&) work the same way. Transport formats, all of them, all reversible by design.

And the = you often see on the end isn’t a lock. It’s padding, there to round the output up to a multiple of four characters.

Encryption: secrecy with a key

Encryption hides data from everyone who doesn’t hold the key. The algorithm itself can be completely public, and usually is: AES is a published standard anyone can read. Security lives in the key, not in the method. Without the key, ciphertext is unreadable in any practical sense. With it, decryption is exact.

So: reversible, but only if you have the key. That’s what makes encryption the right tool whenever data has to be hidden from some people and readable by others. Disk encryption, HTTPS, password managers, sealed messages.

It also brings the thing encoding doesn’t have, which is keys to manage. Generating them, storing them, sharing them safely. Essentially all the real difficulty of encryption lives there, not in the maths.

That gives you a useful smell test. If something calls itself encryption but never asks you for a key, it’s either encoding wearing a costume, or the key management is happening somewhere you can’t see.

Hashing: a one-way fingerprint

A hash squeezes any input down to a fixed-size fingerprint that can’t be run backwards. Feed SHA-256 a single byte or a full terabyte and you get 32 bytes either way. Same input, same hash, every time. Change one bit of the input and the output changes completely.

You can’t reverse it. Not with effort, not with better software, not ever. That’s the whole point of it, not a shortcoming, because it lets a hash answer “is this the same data?” without exposing the data. Hence integrity checks (does this download match the published hash?), password storage (keep the hash, check a login by hashing the attempt, and a stolen database gives up no passwords), deduplication, change detection.

Two warnings worth carrying around. MD5 and SHA-1 are still perfectly good checksums against accidental corruption, but they’re broken against a deliberate attacker, who can manufacture collisions to order. Anything security-relevant wants SHA-256 or better; the hash generator offers all of them and labels which is which.

The second: hashing a password without salting it is barely better than storing it in plain text, because the hashes of common passwords are already tabulated. Real systems use salted, deliberately slow hashes like bcrypt or argon2.

The JWT case, where the confusion does damage

JSON Web Tokens are where all three concepts collide in public. A JWT looks like line noise. Its first two sections are Base64-encoded JSON. Paste one into the JWT decoder and the payload is right there, no key involved.

The third section is a signature, which is hashing plus a key, and it lets the server confirm nobody tampered with the token. A JWT is therefore tamper-evident but not confidential. Whoever holds it can read every claim inside; they just can’t change one without getting caught.

This is why putting sensitive data in a JWT payload is such a common bug. Someone sees gibberish and assumes encryption.

The one-table summary

	Reversible?	Needs a key?	Solves
Encoding (Base64)	Yes, by anyone	No	Transport
Encryption (AES)	Yes, with key	Yes	Secrecy
Hashing (SHA-256)	No	No	Integrity

Next time you’re staring at an unreadable string, don’t ask how to read it. Ask which of the three it is. That answer tells you whether reading it is trivial, hard, or a category error.