Your password is not encrypted, and that is a good thing

“The password is encrypted.” It sounds reassuring, and it is usually wrong, and the mistake behind it has caused real breaches. There are three operations that all turn readable data into unreadable gibberish, so beginners treat them as the same thing: encoding, encryption, and hashing. They look identical from the outside and do completely different jobs. Knowing which is which is one of those small pieces of literacy that separates someone who can talk about security from someone who accidentally leaks it.

Three jobs that look identical from outside

Here they are side by side, because the differences are the whole point:

The column that matters most is “reversible?“. Encoding can be undone by anybody, so it is not security at all. Encryption can be undone, but only by whoever holds the key. Hashing cannot be undone by anyone, on purpose, and that turns out to be exactly what you want for a password.

Morse code, a safe, and a smoothie

Three pictures make it stick.

Encoding is Morse code. You turn “hello” into dots and dashes so it can travel down a telegraph wire. Anyone who knows Morse reads it straight back. It was never meant to be secret; it is just a different format for the same message.

Encryption is a locked safe. You put the message inside and lock it, and only someone with the key can open it and read the original. Take the key away and it is useless gibberish. This is what HTTPS does to every request between your browser and a server.

Hashing is a smoothie. You put fruit in a blender and get a smoothie out. You cannot turn the smoothie back into the fruit, ever. But the same fruit always makes the same smoothie, so if two smoothies are identical, you know the fruit was the same. That “same input, same output, no way back” is the whole trick behind storing passwords.

Why passwords are hashed, never encrypted

Now the sentence from the top makes sense. A well-built site does not store your password, encrypted or otherwise. It stores a hash of it. When you log in, it hashes what you typed and compares the two fingerprints. It never needs to know your actual password, so it never keeps it.

This is why hashing is the right tool and encryption is the wrong one. If a site encrypted passwords, then the key that decrypts them exists somewhere, and the day an attacker gets both the database and that key, every password is readable. With hashing there is nothing to decrypt. A stolen database of hashes does not hand over the passwords, because there is no way back.

// encoding: trivially reversible. this protects NOTHING.
btoa("hunter2")            // "aHVudGVyMg==" ... anyone runs atob() and it is back

// hashing: one-way, and this is how you store a password
const stored = await bcrypt.hash("hunter2", 12)  // "$2b$12$..." cannot be reversed
await bcrypt.compare(attempt, stored)            // you compare fingerprints, never decrypt

Base64 is not a lock

Here is the specific mistake to watch for, because it is everywhere. Base64 is encoding, not encryption. When you see a long string of letters and numbers ending in = and someone calls it “encrypted”, they are wrong, and if they are relying on it to hide something, that thing is exposed. Anyone can paste it into a decoder and read it in one second.

Where you meet each one

Once the three click, you start spotting them everywhere:

• Encoding: Base64 in data URIs and email attachments, the URL-encoding of %20 for a space, the readable parts of a JWT token. All about format, none about secrecy.
• Encryption: HTTPS protecting every request, your password manager’s vault, a database encrypted at rest. All about keeping data private from anyone without the key.
• Hashing: password storage, the checksum that proves a downloaded file was not tampered with, the commit IDs in Git, deduplicating files by content. All about a fingerprint, never about reading the original back.

flowchart TD
  Q{What do you need?} -->|readable in another format, not secret| E[Encoding: Base64, URL encoding]
  Q -->|hidden, but you must read it back later| C[Encryption: needs a key]
  Q -->|verify or store a secret you never read back| H[Hashing: one-way, salted]

Three tools, and the cost of grabbing the wrong one

The lesson is that these three are not interchangeable words for “make it unreadable”. Encoding is for compatibility and hides nothing. Encryption is for privacy and depends entirely on protecting the key. Hashing is for verification and for the things you should never be able to read back, like a password. Reach for the wrong one and you get security theatre: a password you could decrypt if the key leaks, or a secret “protected” by Base64 that a stranger reads in a second. Reach for the right one, and a stolen database of your users’ passwords is worth almost nothing to whoever stole it.

Encode to move it, encrypt to hide it, hash to prove it. Never mix up which.

Sources

• Auth0: encoding, encryption, and hashing for the three purposes and how they differ
• GeeksforGeeks: difference between hashing, encryption and encoding for reversibility and key use
• Packetlabs: encryption, encoding and hashing explained for Base64 as encoding, not security
• OWASP password storage cheat sheet for salting and slow, purpose-built password hashes