Hashing vs Encryption: The Difference

"Hashing" and "encryption" get used interchangeably, and the mix-up causes real security bugs — like encrypting passwords when you should hash them. They solve different problems. The simplest distinction: encryption is reversible, hashing is not.

Encryption: a locked box

Encryption scrambles data so that only someone with the key can unscramble it. It is two-way by design: you encrypt to protect data, and later decrypt to read it. The security depends entirely on keeping the key secret.

Use encryption when you need the original data back:

• Messages in transit (HTTPS encrypts the traffic, then both ends decrypt).
• Files or database fields you will later need to read, like stored API tokens or someone's address.
• Anything where "lock it now, open it later" is the requirement.

There are two flavours: symmetric (one shared key for both locking and unlocking, fast, good for bulk data) and asymmetric (a public key to lock, a private key to unlock, the basis of TLS and digital signatures).

Hashing: a one-way fingerprint

Hashing runs data through a function that produces a fixed-size string — the hash — and cannot be reversed. There is no key and no "unhash". The same input always gives the same hash, but from the hash you cannot recover the input.

That sounds less useful until you see what it is for: proving something without storing the thing itself.

• Integrity. Hash a file before and after transfer; if the hashes match, nothing changed. A single altered byte produces a completely different hash.
• Passwords. You store the hash of a password, never the password. At login you hash what the user typed and compare hashes. A breach of the database leaks hashes, not passwords.
• Deduplication and lookups. Identical content produces identical hashes, a quick way to spot duplicates.

The password rule that matters

Here is the bug the confusion causes: never encrypt passwords. Encryption is reversible, so an attacker who gets the key gets every password. You do not need to recover passwords — you only need to check them — so hashing is correct.

But not just any hash. Fast hashes like MD5 or SHA-256, designed for speed, are the wrong choice for passwords precisely because they are fast: an attacker can try billions of guesses per second. Passwords need a slow, salted hash built for the job — bcrypt, scrypt or Argon2 — which:

• Salts each password with a unique random value, so identical passwords get different hashes and precomputed "rainbow table" attacks fail.
• Is deliberately slow and tunable, so brute-forcing is painfully expensive.

So: general data integrity → a fast hash like SHA-256. Storing passwords → a slow hash like bcrypt. Protecting readable data → encryption.

Encoding is neither

One more thing often lumped in: encoding (like Base64) is not security at all. Base64 just rewrites data in a different alphabet so it survives transport; anyone can decode it instantly with no key. It provides zero confidentiality. If something is "Base64 encrypted", it is not encrypted.

The quick decision guide

• Need the original data back later? → Encryption (keep the key safe).
• Need to verify a file or message is unchanged? → a hash (SHA-256 and friends).
• Storing passwords? → a slow, salted hash (bcrypt, scrypt, Argon2) — never encryption, never a fast hash.
• Just need data to survive transport? → encoding, and do not mistake it for protection.

Generating hashes with common algorithms to verify a file, producing a proper bcrypt hash for a password, and encoding or decoding Base64 to see how reversible it really is all run from your browser. They make the difference concrete: watch a one-character change rewrite a hash entirely, and watch Base64 decode back in an instant with no key at all.