Encryption vs Hashing: Differences and When to Use Each
Encryption vs hashing explained: reversible vs one-way, keys vs salts, passwords, file integrity and signatures, with the OWASP settings for storing passwords.
Encryption is reversible: you scramble data with a key and anyone holding the right key can unscramble it. Hashing is one-way: you turn data into a fixed-length fingerprint that cannot be turned back into the original. Use encryption when you need to read the data again later. Use hashing when you only need to check that something matches, such as a password or a file.
Confusing the two is a classic security mistake. This guide shows the difference, which to use for what, and how to store passwords properly.
Key takeaways
- Encryption is two-way, and needs a key to reverse it.
- Hashing is one-way, has no key to reverse it, and always gives a fixed-size output.
- Never encrypt passwords to store them. Hash them with a slow, salted algorithm built for passwords.
- A fast hash such as plain SHA-256 is wrong for passwords. Use Argon2id, scrypt or bcrypt.
- Encryption protects confidentiality. Hashing helps with integrity and verification.
Side-by-side
| Encryption | Hashing | |
|---|---|---|
| Direction | Two-way (encrypt and decrypt) | One-way |
| Needs a key | Yes | No (salt or pepper may be added) |
| Output size | Roughly the size of the input | Fixed, e.g. 256 bits for SHA-256 |
| Goal | Keep data secret but recoverable | Verify or fingerprint data |
| Typical uses | Files, databases, messages, HTTPS | Password storage, integrity checks, signatures |
| Example algorithms | AES, RSA, ChaCha20 | SHA-256, SHA-3, Argon2id, bcrypt |
What is encryption?
Encryption transforms readable data (plaintext) into unreadable data (ciphertext) using an algorithm and a key. With the correct key you reverse it. Symmetric encryption uses one shared key, and asymmetric encryption uses a key pair. See symmetric vs asymmetric encryption.
What is hashing?
A hash function takes input of any size and returns a fixed-length digest. A good one has three properties: the same input always gives the same output, you cannot work backwards from the digest, and finding two inputs with the same digest is infeasible. Change one character of the input and the digest changes completely.
When to use which
| Need | Use |
|---|---|
| Store a user's password | Hashing (a password hash) |
| Protect data you must read later, such as a stored document | Encryption |
| Confirm a downloaded file was not altered | Hashing (compare digests) |
| Send a private message | Encryption |
| Secure a web connection | Encryption (TLS) |
| Create a digital signature | Hashing plus asymmetric cryptography |
How to store passwords
The OWASP Password Storage Cheat Sheet recommends, in order of preference:
- Argon2id with a minimum of 19 MiB of memory, 2 iterations and 1 degree of parallelism.
- scrypt, if Argon2id is unavailable, with a minimum cost parameter of 2^17, block size 8 and parallelism 1.
- bcrypt for legacy systems, with a work factor of 10 or more. Note bcrypt's 72-byte password limit.
- PBKDF2 where FIPS-140 compliance is needed, with 600,000 or more iterations using HMAC-SHA-256.
Always use a unique random salt per password, which good libraries do for you. A salt makes identical passwords hash differently and defeats precomputed lookup tables. These are minimums: check the current OWASP page, since recommendations change.
Why not plain SHA-256?
General-purpose hashes are designed to be fast. That is a strength for file checks and a weakness for passwords, because an attacker can test billions of guesses per second. Password hashes are deliberately slow and memory-hungry to make guessing expensive.
Hashing is not always safe
MD5 and SHA-1 have known collision attacks and should not be used for security purposes. Use SHA-256 or SHA-3 for integrity and signatures. Also remember that a hash of a weak password is still weak: attackers guess common passwords and compare hashes.
Common mistakes
- Encrypting passwords so they can be "recovered". If you can decrypt them, so can an attacker who gets the key.
- Using a fast hash with no salt for passwords.
- Storing the encryption key next to the encrypted data.
- Rolling your own algorithm instead of a vetted library.
- Confusing encoding with encryption. Base64 is not secure, it is just a different format.
Where this fits in your app
Hashing and encryption are building blocks of login, sessions and APIs. See authentication vs authorization and AI guardrails and safety for how security thinking applies across a system.
Need a security review?
We build and review authentication, data protection and API security for web and AI products. Get a scope estimate for your project.
FAQ
What is the difference between encryption and hashing?
Encryption is reversible with a key. Hashing is one-way and cannot be reversed. Encryption keeps data secret but recoverable, while hashing verifies data matches.
Can a hash be decrypted?
No. Attackers do not decrypt hashes. They guess inputs, hash them and compare. This is why slow, salted password hashes matter.
Should passwords be encrypted or hashed?
Hashed, using Argon2id, scrypt, bcrypt or PBKDF2. Encrypted passwords can be recovered if the key leaks.
Is SHA-256 encryption?
No, it is a hash function. It produces a fixed 256-bit digest and cannot be decrypted. It is also not suited to password storage on its own.
What is a salt?
A random value added to each password before hashing so that identical passwords produce different hashes and precomputed tables do not work.
Is Base64 encryption?
No. Base64 is an encoding for representing binary data as text. Anyone can decode it, so it gives no security.