The Core Difference: Reversible vs One-Way
Everything follows from one distinction:
- Encryption is reversible. You scramble data with a key, and anyone with the correct key can unscramble it back to the exact original. Its purpose is confidentiality — keeping data secret from anyone without the key.
- Hashing is one-way. You feed data through a hash function and get a fixed-size fingerprint. There is no key and no reverse operation — you cannot turn the fingerprint back into the data. Its purpose is integrity and identity — proving that data is what it claims to be, or hasn't changed.
Encryption asks "can the right person read this later?" Hashing asks "is this exactly the same as before, and can I check without storing the original?" Different questions, different tools.
What a Hash Function Actually Does
A hash function takes input of any length — a password, a file, an entire disk image — and produces an output of fixed length, called a hash or digest. A widely used example, SHA-256, always produces 256 bits (64 hexadecimal characters) regardless of whether the input is one byte or one gigabyte. A good cryptographic hash function has four defining properties:
- Deterministic — the same input always yields the same digest.
- Fast to compute in the forward direction.
- Irreversible (preimage resistant) — given a digest, you cannot feasibly find an input that produced it.
- Avalanche effect — changing a single character of input produces a completely different, unpredictable digest.
It should also be collision resistant: it must be infeasible to find two different inputs that hash to the same value. These properties are what make a hash a trustworthy fingerprint.
Side by Side
| Property | Hashing | Encryption |
|---|---|---|
| Direction | One-way (irreversible) | Two-way (reversible with a key) |
| Uses a key? | No | Yes |
| Output size | Fixed, regardless of input | Varies with input size |
| Goal | Integrity, verification, identity | Confidentiality |
| Can you recover the original? | No | Yes, with the key |
| Examples | SHA-256, SHA-3, BLAKE2 | AES, ChaCha20, RSA |
Why Passwords Are Hashed, Not Encrypted
This is the question that makes the distinction click. A well-built service does not store your password at all — it stores a hash of it. When you log in, it hashes what you typed and compares the two digests. A match means the password is correct, even though the original was never kept.
Why not encrypt instead? Because a system has no legitimate need to ever recover your original password — it only needs to check matches. Encryption would mean storing a decryption key somewhere, and if an attacker steals the database they may steal that key too, exposing every password at once. A hash has no key to steal: a breach of hashed passwords does not directly reveal them.
Two refinements make this robust. A unique random salt is added to each password before hashing, so identical passwords produce different digests and precomputed lookup tables (rainbow tables) are useless. And deliberately slow password-hashing functions (such as bcrypt, scrypt, or Argon2) are used instead of fast general-purpose hashes, so that an attacker who does get the hashes can only test guesses agonisingly slowly.
Where Each One Shows Up
Both techniques are everywhere, often in the same protocol:
- File integrity — a published SHA-256 checksum lets you verify a download arrived intact and unmodified. Re-hash the file; if the digest matches, it is byte-for-byte correct.
- Password storage — salted, slow hashes, as above.
- Digital signatures — a message is hashed, and the hash is then signed, so the signature both proves origin and detects tampering.
- Confidential data — encryption protects anything that must stay secret yet be readable later: messages, files, database fields.
How They Combine in HTTPS
The clearest example of the two working together is the connection securing this page. TLS uses encryption to keep your data confidential as it crosses the network, and it uses hashing (inside message authentication codes) to detect whether any byte was altered in transit. Meanwhile, the certificate that proves the site's identity relies on a digital signature, which hashes the certificate data and signs that hash with a private key. Confidentiality from encryption, integrity and authenticity from hashing — see symmetric vs asymmetric encryption for how the key side of that story fits together. The lock icon in your browser is really both techniques cooperating.
Frequently Asked Questions
What is the difference between hashing and encryption?
Encryption is reversible — data is scrambled with a key and can be unscrambled with the right key, protecting confidentiality. Hashing is one-way — data becomes a fixed-size fingerprint that cannot be reversed, used to verify integrity and identity.
What is a hash function?
A function that turns input of any size into a fixed-length digest. A good cryptographic hash is deterministic, fast, infeasible to reverse, and changes completely with any input change. SHA-256 is a common example.
Why are passwords hashed and not encrypted?
A system only needs to check matches, not recover the original. Storing hashes means a stolen database does not directly reveal passwords, and there is no decryption key to steal. Hashes are salted and computed slowly to resist guessing.
Can a hash be reversed?
No. A cryptographic hash is one-way — there is no key or method to turn a digest back into its input. Attackers can only guess inputs and hash them, which slow salted hashing makes impractical.
Do hashing and encryption work together?
Constantly. TLS encrypts data for secrecy and hashes it for integrity; digital signatures hash a message then sign the hash. Encryption provides confidentiality, hashing provides integrity and authenticity.