Hashing vs Encryption: What's the Difference?

In almost every security discussion, you'll encounter both hashing and encryption. They sound similar but serve completely different purposes. Confusing them leads to serious security mistakes.

Encryption: Reversible Scrambling

Encryption converts plaintext into ciphertext using a key. It's reversible: with the correct key, you can decrypt the ciphertext back to the original plaintext. The whole point is that the original data can be recovered.

Use case: protecting file contents in transit (TLS), storing files at rest (AES-256), sending private messages (Signal).

Hashing: One-Way Fingerprinting

A hash function takes an input of any size and produces a fixed-size output (the hash, or digest). It's deterministic — the same input always produces the same output — but not reversible. You cannot compute the original input from the hash. Even a tiny change to the input produces a completely different hash (the avalanche effect).

Use case: verifying file integrity (SHA-256 checksums), storing passwords (bcrypt, Argon2), detecting file tampering.

Why You Should Never "Encrypt" Passwords

Passwords should be hashed, not encrypted. If you encrypt passwords, you have a decryption key that can recover the original passwords — an enormous security risk. With a proper hash (bcrypt, Argon2), recovering the original password requires brute-force guessing against a computationally expensive function, not just finding a key.

File Integrity with Hashes

When you download a large file — a software installer, a database backup — the publisher often provides a SHA-256 or MD5 checksum. Run the same hash function on your downloaded file and compare the output. If they match, the file arrived intact. If they differ, the file was modified in transit or during storage. This is how file integrity verification works at scale.