Hashing vs Encryption: What's the Difference?

Hashing and encryption are both ways of transforming data so it isn’t sitting in plain, readable form — but they exist for opposite reasons. Encryption is reversible: you scramble data with a key so that anyone holding the right key can unscramble it back to the original. Hashing is one-way: you run data through a function that produces a fixed-size fingerprint, and there is no key and no path back to the input. Confusing the two is one of the most common security mistakes there is, and it usually shows up in exactly the wrong place: how an application stores passwords.

The one-line rule: use encryption when you need to get the data back; use hashing when you never need the data back, only a way to check it.

What hashing does

A hash function takes an input of any size and produces a fixed-length output — a digest — that acts as a fingerprint of the data. Modern cryptographic hash functions like the SHA-2 family have a few defining properties:

• Deterministic. The same input always produces the same digest.
• One-way. Given a digest, you can’t feasibly work backward to the input.
• Collision-resistant. It’s infeasible to find two different inputs that produce the same digest.
• Avalanche effect. Changing a single bit of input changes roughly half the output bits, so similar inputs produce wildly different digests.

Because it’s one-way, hashing is perfect for verification without storage of the original. You don’t store a user’s password; you store its hash. When they log in, you hash what they typed and compare digests. If they match, the password was right — and you never had to keep the actual password anywhere. Hashing also underpins integrity checks: the signature on a JSON Web Token is computed over a hash of the token’s contents, so any tampering changes the digest and invalidates the signature.

What encryption does

Encryption transforms readable plaintext into unreadable ciphertext using an algorithm and a key, and — crucially — the process is reversible with the right key. It comes in two flavors:

• Symmetric encryption uses one shared key for both encryption and decryption (AES is the standard). Fast, ideal for bulk data like files or disk contents.
• Asymmetric encryption uses a key pair: a public key to encrypt and a matching private key to decrypt. Slower, but it solves the key-distribution problem — you can hand out the public key freely.

Encryption is what protects data you genuinely need to read again later: files at rest, database columns holding sensitive fields, and — most visibly — traffic in transit. When you load a site over HTTPS, the connection uses asymmetric encryption to agree on a shared symmetric key, then encrypts the actual data with that faster symmetric cipher. The same asymmetric building blocks are what the industry is racing to upgrade against future quantum computers, the subject of post-quantum cryptography.

Hashing vs encryption at a glance

	Hashing	Encryption
Reversible?	No — one-way	Yes, with the key
Uses a key?	No (may use a salt/secret)	Yes
Output size	Fixed length	Roughly proportional to input
Primary purpose	Verify integrity, store password proofs	Protect confidentiality of readable data
Typical algorithms	SHA-2, bcrypt, Argon2	AES, RSA, elliptic-curve
Get the original back?	Never	That’s the whole point

Why passwords are hashed, not encrypted

This is where the distinction earns its keep. If a database stores encrypted passwords and an attacker steals both the database and the key — which often live near each other — every password is instantly recoverable. If the database stores hashes, there’s nothing to decrypt. The attacker has to guess inputs, hash each guess, and look for a match.

But plain hashing isn’t enough for passwords, for two reasons:

1. General-purpose hashes are too fast. SHA-256 is designed to be quick, which lets an attacker try billions of guesses per second against stolen hashes.
2. Identical passwords produce identical hashes. Without extra input, two users with the same password get the same digest, and precomputed “rainbow tables” can reverse common ones.

The fix is a salt — a unique random value added to each password before hashing, so identical passwords produce different digests and rainbow tables become useless. On top of that, password hashing uses deliberately slow algorithms built for the job — bcrypt, scrypt, or Argon2 — which are tuned to be computationally expensive so that each guess costs the attacker real time and memory. The result: even if the whole database leaks, cracking a well-salted, slow-hashed password is enormously expensive per account.

This is also why modern authentication is moving away from shared secrets entirely. Passkeys replace passwords with public-key cryptography — the server stores only a public key, and there’s no secret to steal in the first place.

Common mistakes to avoid

• Encrypting passwords. If you can decrypt it, so can whoever steals the key. Hash instead.
• Using a fast hash for passwords. SHA-256 alone is wrong for passwords; use bcrypt, scrypt, or Argon2.
• Forgetting to salt. Unsalted hashes are vulnerable to precomputed lookups.
• Rolling your own crypto. Use vetted libraries and standard algorithms. Novel cryptography is almost always broken cryptography.
• Treating hashing as confidentiality. A hash proves you have the right input; it doesn’t hide data you still need to read. For that, you need encryption.

These distinctions matter beyond passwords, too. A zero trust security model leans on both primitives constantly — encryption to protect data moving between services, hashing to verify that tokens and messages haven’t been altered along the way.

The takeaway

Hashing is a one-way fingerprint you use to verify data; encryption is a reversible transformation you use to protect data you’ll need to read again. Store password proofs as salted, slow hashes — never as encrypted values you could decrypt. Encrypt the things you must recover later, in transit and at rest. Get which tool goes where right, and you’ve avoided the single most common category of applied-crypto mistake.