No. Hashing turns data into a fixed-length digest designed for checks such as integrity verification; encryption turns readable data into ciphertext that an authorized party can decrypt. The key difference is that hashing is designed to be one-way, while encryption is designed to be reversible with the appropriate key.
How hashing and encryption work
Hashing produces a digest
A cryptographic hash function maps input of varying lengths to a fixed-length output called a digest. NIST describes a cryptographic hash function in its glossary. Hashes can help detect whether data has changed since a trusted digest was generated. They are not a way to conceal data, and there is no decryption step that restores the original input.
For example, NIST’s published FIPS 180-4 specifies SHA-256 with a 256-bit message digest and SHA-512 with a 512-bit digest. These are standard parameters, not guarantees that any system using the algorithms is secure. The standard lists other SHA-2 variants as well. See FIPS 180-4.
Encryption conceals data and permits recovery
Encryption transforms plaintext into ciphertext to conceal its meaning; decryption uses the appropriate key and algorithm to recover the plaintext. NIST’s encryption glossary defines encryption as the cryptographic transformation of data to produce ciphertext. Encryption uses key material; in public-key encryption, the encryption key may be public while a separate corresponding key is used to decrypt.
#1 Best Overall
Hashing vs. encryption at a glance
| Question | Hashing | Encryption |
|---|---|---|
| Main purpose | Produce a fixed-length digest for checks such as integrity or password verification | Conceal plaintext so an authorized party can recover it |
| Can the original be recovered? | No decryption step; designed to be one-way | Yes, through decryption with the appropriate key |
| Does it use a key? | A basic hash such as SHA-256 is unkeyed; keyed-hash constructions also exist for other purposes | Uses cryptographic key material |
| Common example | Comparing a file digest or verifying a stored password | Protecting a file or message that must later be opened |
| Important limit | A plain digest does not provide confidentiality or establish who created the data | Encryption alone does not necessarily provide integrity or authenticity |
Why a hash is not automatically proof of authenticity
If you compare a file’s digest with an expected digest obtained from a trusted source, a mismatch can reveal that the file changed. But an ordinary hash alone does not prove who created the file: someone who can replace both the file and the expected digest can make them match. Authentication requires an appropriate mechanism, such as a keyed construction or digital signature. Likewise, encryption should use an appropriate authenticated construction when integrity and authenticity are required; encryption by itself should not be treated as proof of either.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why websites store password hashes instead of encrypted passwords
Password verification usually needs to check a submitted password, not recover the account holder’s original password. A verifier can apply the same password-hashing process to the submitted password and compare the result with its stored value. If the verifier file is stolen, an attacker can still try candidate passwords, but a suitable password-hashing scheme is designed to make each guess more expensive. Weak or commonly used passwords may still be guessed.
NIST’s 2025 edition of SP 800-63B says verifiers must store passwords in a form resistant to offline attacks and that passwords “SHALL be salted and hashed using a suitable password hashing scheme.” It describes the scheme as taking the password, a salt, and a cost factor as inputs. NIST says the cost factor should be as high as practical without harming verifier performance, and should rise over time as computing performance improves.
- A salt is stored with the resulting hash for each password; it helps avoid identical passwords having identical stored verifier values and helps minimize collisions among stored hashes.
- A cost factor makes each candidate guess more computationally expensive. NIST’s guidance calls for keeping a reference to the scheme and cost factor so they can be updated or migrated.
- NIST SP 800-63B-4 specifies a minimum salt length of 32 bits. That is the requirement stated in this edition, not a claim that 32 bits is the ideal salt length for every modern implementation.
The guidance also describes an optional additional keyed-hashing or encryption operation using a secret stored separately, ideally in hardware-protected storage. This is an extra layer, not a replacement for password hashing. A fast general-purpose digest such as plain SHA-256 alone should not be presented as a suitable password-storage scheme.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Best Value
Which should you use?
- To check whether data matches a trusted reference: use a cryptographic digest, while ensuring the expected digest itself comes from a trusted source.
- To store passwords for later verification: use a suitable salted password-hashing scheme with an appropriate cost factor, not recoverable encryption.
- To protect information that must later be read: encrypt it and protect the necessary keys.
- To establish who created or approved data: use an appropriate authentication mechanism; a plain hash is not enough.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
