What is the difference between hashing and encryption?

Hashing is a one-way transformation: you can turn a password into a hash, but you cannot reverse the hash back to the password without brute force. Encryption is two-way: you encrypt data with a key and decrypt it with the same key (or a paired key). Use hashing to verify data without storing it; use encryption when you need to recover the original data later.

Can you decrypt a hash?

No. A hash function is mathematically one-way — there is no decryption operation. The only way to find the original input is to guess inputs and compare hashes, which is why slow hash functions like Argon2id make password cracking impractically expensive. This is a design feature, not a limitation.

Is SHA-256 encryption or hashing?

SHA-256 is a hash function, not encryption. It has no key, produces a fixed 256-bit output regardless of input size, and is not reversible. It is used for integrity verification, digital signatures, and password storage — not for keeping data confidential.

Why are passwords hashed instead of encrypted?

If you encrypt passwords, a single compromised encryption key exposes every password in your database at once. If you hash passwords with a slow function like Argon2id, an attacker who steals the database still has to crack each hash individually, one at a time. Hashing is the correct choice because you only need to verify the password, not recover it.

What happens if two inputs have the same hash?

This is called a hash collision. Modern hash functions like SHA-256 are designed to make collisions computationally infeasible to find. MD5 and SHA-1 have both had collisions demonstrated — SHA-1's first collision was shown in 2017 by Google researchers and cost approximately $110,000 in cloud compute. This is why MD5 and SHA-1 are no longer acceptable for security purposes.

Is MD5 safe to use for passwords?

No. MD5 is broken for security use. It is fast (which means attackers can try billions of guesses per second), and real-world collisions have been demonstrated since 2004. NIST has disallowed MD5 for cryptographic use since 2011 (SP 800-131A). For passwords, use Argon2id or bcrypt at a minimum.

Hashing vs Encryption: Which One Do You Need?

Introduction

Every week, developers store passwords with encryption instead of hashing. And every week, a single leaked database key exposes every user account at once.

Hashing vs encryption is the most consequential decision in how you protect user data — and it is also the most commonly confused one. The two tools solve fundamentally different problems. Using the wrong one does not just produce a less secure system; it produces a broken one.

In the 2013 Adobe breach, 153 million user records were exposed. Adobe had encrypted passwords rather than hashing them. Because they used the same key for every account, attackers could identify users with identical passwords by finding identical ciphertexts. Worse, once the key was exposed, every password was decryptable in bulk. A hashed database would have required attackers to crack each account individually.

In the 2019 Facebook incident, hundreds of millions of passwords were found stored in plaintext internal logs. No hashing, no encryption — just readable strings.

Both of these failures share a root cause: the engineers responsible did not clearly understand when to hash and when to encrypt. This article gives you the decision framework that prevents both mistakes.

What Is Hashing?

Hashing is a one-way mathematical transformation. You feed any input — a password, a file, a document — into a hash function, and it produces a fixed-size output called a digest or hash. No key is involved. The same input always produces the same output. Different inputs should produce different outputs.

The critical property is irreversibility. Given the SHA-256 hash of “correct horse battery staple”, there is no algorithm that reverses it back to the original phrase. You can only verify a guess: hash the guess and compare.

NIST defines three formal security properties for hash functions in SP 800-107. For password storage specifically, modern systems use memory-hard functions like Argon2id rather than fast hashes like SHA-256.

Pre-image resistance: Given a hash, it is computationally infeasible to find any input that produces it.
Second pre-image resistance: Given an input and its hash, it is infeasible to find a different input with the same hash.
Collision resistance: It is infeasible to find any two different inputs that produce the same hash.

SHA-256 is currently NIST-approved and recommended. MD5 and SHA-1 have had real-world collisions demonstrated — they are disallowed for cryptographic use.

What Is Encryption?

Encryption is a two-way transformation that uses a key. You encrypt data with a key to produce ciphertext. You decrypt the ciphertext with the correct key to recover the original data. The key is what makes the operation reversible — without it, the ciphertext is indistinguishable from random noise.

Symmetric encryption (like AES-256-GCM) uses one key for both encryption and decryption. Asymmetric encryption (like RSA) uses a public key to encrypt and a private key to decrypt. Both are reversible by design.

The point of encryption is that you need the original data back later. Encrypted database fields, file storage, HTTPS traffic — all of these require decryption to be useful.

How Hashing vs Encryption Works

When to Hash

The decision rule is simple: hash when you will never need the original value back.

Passwords are the most important case. When a user logs in, you hash their input and compare it to the stored hash. You never need to know what their password actually is — only whether their guess matches. Using a slow hash function like Argon2id (OWASP-recommended) adds deliberate computational cost. At bcrypt cost=12, one hash takes approximately 250 ms. One million cracking attempts would take 2.9 days per GPU — making bulk cracking economically unattractive.

File integrity is another case. SHA-256 of a file before and after transmission confirms nothing was corrupted or tampered with. You only need to verify the hash matches — you do not need to transform the hash back into the file.

Digital signatures work by hashing the document, then signing the hash with a private key. You verify by hashing the document again and checking the signature against the public key.

When to Encrypt

Encrypt when you need to recover the original data later.

Sensitive database fields that must be displayed to an authorized user — credit card last four digits, SSNs, medical record fields — must be encrypted, not hashed. You need the actual value back.

Data in transit (HTTPS, TLS, VPNs) uses encryption so the receiver can read the original message.

File storage for documents that users need to download uses encryption so the server can serve the file.

This video covers how hash functions work and why their security properties matter. After watching, return to the encryption section above to see why hashing and encryption are not interchangeable.

Hashing vs Encryption

The key visual is directionality — hash functions flow one way with no key; encryption flows both ways with a key required to reverse. Notice that hashing output is always fixed-size regardless of input.

Feature	Hashing	Symmetric Encryption	Asymmetric Encryption
Reversible	No	Yes (with key)	Yes (with private key)
Key required	No	Yes (shared)	Yes (key pair)
Output size	Fixed (e.g., 256 bits)	Approximately input size	Larger than input
Primary use	Integrity, password storage	Data at rest and in transit	Key exchange, signatures
Examples	SHA-256, Argon2id	AES-256-GCM	RSA, ECC
Speed	Very fast (SHA-256) or slow by design (Argon2id)	Fast with hardware	Much slower

The table reveals why using encryption for passwords is dangerous. Encryption output is the same size as the input — two users with the same password produce identical ciphertexts under the same key, leaking that their passwords match. Hash functions avoid this with salting: a random value added before hashing ensures two identical passwords produce completely different digests. For a deep dive into how modern systems combine this public salt with a secret key to prevent offline cracking, read Salt vs Pepper in Password Hashing.

Real-World Use Cases

User authentication systems: Every production web application should hash passwords with Argon2id (OWASP first recommendation) or bcrypt (second recommendation). The hash is stored in the database. When the user logs in, the server hashes the entered password with the same salt and compares to the stored hash. The server never touches the original password after the user typed it.

File download verification: Software distributions publish SHA-256 hashes alongside their downloads. Before installing, you can verify that the file you downloaded matches the published hash — confirming it was not corrupted in transit or replaced by a malicious version. This is pure integrity verification with no encryption involved.

TLS certificate signatures: TLS certificates use SHA-256 internally. The certificate authority hashes the certificate contents and signs the hash with its private key. When your browser verifies a certificate, it hashes the same contents and checks the signature — confirming the certificate was issued by a trusted authority and has not been modified.

Common Mistakes to Avoid

Hashing passwords with SHA-256 directly. SHA-256 is a general-purpose hash function designed to be fast. Fast is exactly wrong for passwords — it lets attackers try billions of guesses per second. Use purpose-built password hashing functions: Argon2id, bcrypt, or scrypt. These are intentionally slow and configurable.

Encrypting passwords thinking they are safer. If you encrypt passwords with AES, a single key compromise exposes every password at once. With proper hashing, each cracked password requires separate effort. The correct answer is to never need to recover passwords at all — hash them.

Using MD5 or SHA-1 for anything security-related. Google and CWI Amsterdam demonstrated the first full SHA-1 collision in February 2017. The attack required 9.2 quintillion SHA-1 computations and cost approximately $110,000 in cloud compute — within reach of well-funded attackers. MD5 collisions have been achievable since 2004 with consumer hardware. NIST disallowed both for cryptographic use in SP 800-131A.

Forgetting to salt hashes. An unsalted hash of “password123” is the same in every database worldwide. Attackers precompute these in rainbow tables — lookup structures that crack common passwords instantly. A unique random salt per password makes precomputation impossible. All modern password hashing libraries apply salts automatically.

Double-hashing for “extra security.” Hashing a password twice with SHA-256 does not double the security — it can actually reduce the effective output space by introducing structure that attackers can exploit. Trust the algorithm. Use a single, purpose-built slow hash function.

Getting Started

When assessing your current system, find every place in your codebase where user credentials are stored. The storage format tells you everything: plaintext is a critical vulnerability; encrypted passwords are a moderate vulnerability (swap them for hashed passwords); MD5 or SHA-1 hashes are a vulnerability (migrate to Argon2id or bcrypt); bcrypt or Argon2id hashes are correct.

For new systems, the OWASP Password Storage Cheat Sheet is your authoritative reference. It ranks Argon2id as the first choice, bcrypt as the acceptable fallback, and explicitly disallows MD5, SHA-1, and unsalted hashes.

Audit your non-password data as well. Any field containing sensitive personal data — SSN, payment card information, medical records — should be encrypted at rest with AES-256-GCM, not hashed (since you need to display the value to authorized users). Any field used only for verification — security question answers, account confirmation codes — can be hashed.

For the encryption side of this decision, see how AES encryption works. To understand how TLS uses both hashing and encryption together to secure every HTTPS connection, read TLS 1.3 vs TLS 1.2.