Hashing, Encryption, and Encoding Are Not the Same Thing

Few mix-ups cause as much quiet damage as treating hashing, encryption, and encoding as rough synonyms for “scramble the data.” They are three different operations with three different purposes, and the difference isn’t pedantic — it’s the difference between a password that’s safe when your database leaks and one that isn’t, between “protected” and “trivially readable.” Here’s the clean version, and why getting it wrong ships real bugs.

Encoding: reversible by anyone, protects nothing

Encoding transforms data into a different format for compatibility, not secrecy. Base64, URL-encoding, hex, character sets — they exist so data survives a channel that expects a certain shape (safe characters in a URL, binary in a text field). The defining property: anyone can reverse it, no key required. That’s not a weakness; it’s the entire point. The transformation is public and deterministic.

Which is exactly why encoding is not security. Base64 looks scrambled to a human, and that resemblance to “encrypted” is where the danger lives — people see the gibberish and assume it’s protected. It isn’t. Anyone can decode it in one step. If you’ve “secured” a token or a config value by Base64-ing it, you’ve obscured it from a casual glance and protected it from absolutely no one.

Encoding is a costume, not a lock. It changes how data looks, not who can read it.

Encryption: reversible only with the key

Encryption transforms data so that only someone with the right key can reverse it. That key is the whole difference from encoding — take the key away and the ciphertext is useless. Encryption is for confidentiality: keep the plaintext readable to key-holders and opaque to everyone else. It comes in two flavors worth knowing:

• Symmetric — the same key encrypts and decrypts. Fast, great for bulk data (encrypting a column, a disk, a file). The challenge is getting the shared key to both sides safely.
• Asymmetric — a public key encrypts, a different private key decrypts (and the reverse for signatures). Slower, but it solves key distribution: you can hand out the public key freely. This is what makes TLS and certificates work.

The critical property: encryption is meant to be reversed — by the right party. You encrypt because you intend to get the plaintext back later. Which makes it exactly the wrong tool for one very common job.

Hashing: not meant to be reversed at all

Hashing runs data through a one-way function to a fixed-size digest, and — done right — there is no key and no way back. You can’t “decrypt” a hash, because it was never encrypted; information is deliberately destroyed. The same input always yields the same hash, but you can’t run it backward to recover the input. Hashing is for verification and integrity: proving two things are the same, or that something hasn’t changed, without storing the thing itself.

This is why passwords should be hashed, not encrypted. If you encrypt passwords, the key exists somewhere, and whoever gets the key gets every password. If you hash them (with a salt, using a slow password-hashing function built for the job), then even a full database leak doesn’t hand over the passwords — an attacker only has digests they can’t reverse, and has to grind guesses against them. “We encrypt passwords” is a sentence that should make you nervous; the right answer is “we hash them.”

The confusions that ship bugs

Line up the properties and the classic mistakes become obvious:

	Reversible?	Needs a key?	For what
Encoding	Yes, by anyone	No	Format compatibility
Encryption	Yes, with the key	Yes	Confidentiality
Hashing	No	No	Verification / integrity

• Encrypting passwords instead of hashing them — creates a key whose leak reveals every password. Use a password hash.
• Treating encoding as encryption — Base64 is not protection; a decoded token is a token.
• Trying to “decrypt” a hash — impossible by design; if you can, it wasn’t a real hash (or the input space is small enough to brute-force, which is its own failure).
• Reaching for encryption when hashing fits — if you only need to check a value, not recover it, hashing is safer because there’s no key to steal.

Pick the tool by the question

The clean way to choose: ask what you actually need. Does this need to survive a text-only channel? Encoding. Does this need to stay secret but be readable again by the right party later? Encryption — and then it’s a threat-model question about where and with whose key. Do I only ever need to verify it or prove it’s unchanged, never read it back? Hashing. Three questions, three tools, and none of them is “scramble it and hope.” The confidence with which this trio gets muddled is exactly what makes it dangerous — so it’s worth being the person on the team who says the precise word. If you’ve caught a hashing-vs-encryption mix-up before it shipped, I’d like to hear about it.