Delimiter.live
Comparison

Hashing vs Encryption

Hashing is one-way: it turns input into a fixed-length digest that cannot be reversed, and is used to verify rather than to recover. Encryption is two-way: it transforms data so that a key holder can get the original back. Use hashing for passwords and integrity checks, and encryption when you genuinely need to read the data again later.

Hash Generator

Generate MD5, SHA-1, SHA-256 and SHA-512 digests at once.

Open the tool

These are often described as two ways of "scrambling" data, which is where the confusion starts. They are built for opposite purposes. Hashing deliberately destroys information so the original cannot be recovered. Encryption deliberately preserves it so the right person can.

The practical consequence is that choosing wrongly is not a matter of taste. Encrypting passwords instead of hashing them creates a database where every password is recoverable by anyone who obtains the key — and the key is usually on the same server.

The core difference

  • Direction: hashing is one-way; encryption is reversible with the key.
  • Key: hashing needs none; encryption is meaningless without key management.
  • Output size: a hash is fixed-length regardless of input; ciphertext grows with the plaintext.
  • Purpose: hashing answers "is this the same?"; encryption answers "keep this secret until I need it".
  • Failure mode: a leaked hash of a strong password is near-useless; a leaked key exposes everything it protected.

When to hash

Whenever you need to check a value without storing it. Password storage is the obvious case: you never need the password back, only to confirm someone supplied the same one. Integrity checking is the other — a checksum proves a file arrived unaltered. Deduplication and cache keys are hashing too, though those need no cryptographic strength.

  • Passwords — with a slow, salted function such as bcrypt or Argon2id, never a bare SHA-256.
  • File and download integrity — SHA-256.
  • Message authentication with a shared secret — HMAC.
  • Content addressing, deduplication, cache keys.

When to encrypt

Whenever the original value has to be readable again. A stored payment token, a document at rest, a message in transit, an API credential your application must present to a third party — none of those work if the data is destroyed.

  • Data in transit — TLS.
  • Data at rest that must be read back — AES-GCM or another authenticated cipher.
  • Secrets your application must present elsewhere, such as third-party API keys.
  • Anything where "we need to show this to the user again" is a requirement.

The mistake that matters

Encrypting passwords. It sounds more secure because it sounds stronger, and it is strictly worse: it turns an irreversible store into a reversible one. Anyone who obtains the key — a backup, a config file, an attacker already inside the server — recovers every password in plaintext. Hashing has no key to leak. If a system can email you your existing password, it is not hashing them, and that is a reportable weakness rather than a convenience feature.

Where they work together

Real systems use both, for different jobs. TLS encrypts the connection and uses hashes inside its handshake and message authentication. A signed JWT is hashed via HMAC and sent over an encrypted channel. Encrypted data is often hashed afterwards to detect tampering — which is exactly what an authenticated cipher such as AES-GCM does for you.

Frequently asked questions

Is hashing more secure than encryption?
Neither is more secure; they solve different problems. Hashing is the right answer when you never need the value back, encryption when you do. Using either for the other's job is what creates the weakness.
Why is encrypting passwords a bad idea?
Because it makes them recoverable. Encryption requires a key, the key lives somewhere reachable by the application, and anyone who gets both the database and the key gets every password in plaintext. Hashing has no key, so there is nothing equivalent to steal.
Can a hash be decrypted?
No — there is nothing to decrypt. Hashing discards information, so there is no inverse operation. Short or common inputs can still be found by looking the digest up in a precomputed table, which is why password hashes must be salted and slow.
Where does encoding fit in?
Nowhere near either. Base64 and URL encoding are reversible with no key at all — they exist to move data through text-only channels, not to protect it. Anything Base64-encoded is readable by anyone who receives it.
What about signing — is that hashing or encryption?
Signing uses both ideas. A signature is a hash of the content combined with a key, so it proves authenticity and integrity without hiding anything. HMAC does this with a shared secret; public-key signatures do it with a private key.

Tools used in this guide

All tools →
All guides →

Last reviewed .