Hashing vs. Encryption: What’s the Difference?

Hashing and encryption are essential cryptographic techniques, but they solve different problems. Hashing helps verify data integrity and supports secure password verification; encryption protects the confidentiality of data that authorized parties must be able to read later.

Hashing: Computes a fixed-size digest (for most common cryptographic hash functions) from input data. It is intended to be a one-way operation.
Encryption: Transforms readable plaintext into ciphertext using a cryptographic key. Authorized parties can decrypt it using the required key.

Hashing vs. encryption at a glance

Feature	Hashing	Encryption
Primary purpose	Data integrity, password verification, and related operations	Data confidentiality
Reversible?	No decryption operation exists	Yes, with the correct key
Key required?	Not for an ordinary cryptographic hash function	Yes
Output	Typically a fixed-length digest	Ciphertext whose size depends on the scheme and input
Repeated input	Same hash function and input produce the same digest	Output may vary with the nonce/IV and other parameters
Typical applications	File checksums, signatures, password verification	HTTPS, databases, storage, backups
Examples	SHA-256, SHA-3, Argon2id for passwords	AES-GCM, ChaCha20-Poly1305

Hashing is not encryption with the key discarded. Nor does a hash, by itself, make its input confidential.

What is hashing?

A cryptographic hash function converts an arbitrary-length input into a digest. For example, SHA-256 produces a 256-bit digest (64 hexadecimal characters), regardless of input length.

Input data ── SHA-256 ──> 256-bit digest

Secure cryptographic hash functions are designed to provide:

Preimage resistance: Finding an input matching a given digest should be computationally infeasible.
Second-preimage resistance: Given an input, finding a different input with the same digest should be infeasible.
Collision resistance: Finding any two distinct inputs that produce the same digest should be infeasible.

Because there are more possible inputs than fixed-length outputs, collisions must exist mathematically. Security means they are difficult to find, not that they are impossible.

Common uses of hashing

Use case	How it works	Important limitation
File integrity	Compare a downloaded file’s SHA-256 digest with a published digest	The expected digest must come from a trusted source
Password verification	Store a password-specific derived hash and verify submitted passwords	Use Argon2id or another purpose-built method, not bare SHA-256
Digital signatures	A message digest is incorporated into a signature scheme	A digest alone is not a signature and does not establish identity
HMAC	A secret key and hash function authenticate a message	HMAC is keyed, unlike ordinary hashing
Blockchains	Hashes link and identify blocks and other data	Hashing is only one part of overall blockchain security

What is encryption?

Encryption converts plaintext into ciphertext and allows authorized decryption.

Plaintext ── Encrypt (key) ──> Ciphertext
Plaintext <── Decrypt (key) ─── Ciphertext

Symmetric and asymmetric encryption

Feature	Symmetric encryption	Asymmetric (public-key) encryption
Keys	The same shared secret key is used for encryption and decryption	A public/private key pair is used
Strength	Efficient for large amounts of data	Useful for establishing secrets and protecting small amounts of data
Examples	AES, ChaCha20	RSA-OAEP
Typical applications	Storage and data in transit	Hybrid encryption and protecting encryption keys

Public-key cryptography also supports digital signatures and key agreement. A digital signature should not simply be described as encrypting with a private key; signatures and encryption are distinct operations with different security goals.

Common uses of encryption

Use case	Example
Websites	HTTPS using TLS
Databases	Encrypting sensitive fields or stored data
Devices	Full-disk encryption
Backups	Encryption during transfer and at rest
Cloud services	Encryption combined with KMS or HSM-based key management

Modern TLS 1.3 establishes shared keys using cryptographic key agreement and then protects application data using efficient authenticated encryption. Older descriptions of SSL key transport do not accurately describe every modern TLS connection.

Common algorithms and standards

Hash functions and password hashing

Algorithm	Standard or specification	Guidance
MD5	RFC 1321	128-bit digest; broken collision resistance; avoid for new security-sensitive uses
SHA-1	FIPS 180-4	160-bit digest; practical collision attacks; avoid for new security-sensitive uses
SHA-256 / SHA-512	NIST FIPS 180-4 (SHA-2)	Widely used cryptographic hashes
SHA3-256 / SHA3-512	NIST FIPS 202 (SHA-3)	A different internal design from SHA-2; SHA-2 is not inherently obsolete
Argon2id	RFC 9106	Memory-hard password hashing; a strong default for new password storage
scrypt	RFC 7914	Memory-hard password-based key derivation
bcrypt	OpenBSD-based scheme	Common in existing systems; note input-length limitations
PBKDF2	NIST SP 800-132 and related specifications	Password-based key derivation, especially when compatibility or compliance requires it

Encryption algorithms and modes

Algorithm / mode	Standard or specification	Guidance
AES-128 / AES-256	NIST FIPS 197	Widely adopted block cipher; numbers indicate key length in bits
AES-GCM	NIST SP 800-38D	Authenticated encryption with associated data (AEAD)
ChaCha20-Poly1305	RFC 8439	AEAD scheme suitable for many software environments
RSA-OAEP	RFC 8017	Public-key encryption scheme
3DES / TDEA	Legacy standards	Do not choose for new system designs

AES specifies the block cipher; GCM specifies a mode of operation. Merely stating that a product uses AES-256 does not establish that it provides authenticated encryption or handles nonces and keys securely.

Security considerations

1. Do not store passwords as plain SHA-256 hashes

One-way hashing does not eliminate password guessing. An attacker who obtains password hashes can compute hashes for candidate passwords and compare them. Weak or reused passwords may be recovered by dictionary or brute-force attacks.

For new password storage, prefer Argon2id with appropriate cost parameters and a unique random salt per password. Depending on requirements and platform support, scrypt, bcrypt, or PBKDF2 may also be appropriate. Salt values generally do not need to be secret and may be stored with password hashes.

Registration: password + unique salt ── Argon2id ──> stored hash
Login: submitted password ── verify using stored parameters ──> match / no match

A salt prevents efficient reuse of precomputed attacks across accounts; it does not turn a weak password into a strong password.

2. A matching digest does not prove who supplied a file

If an attacker can replace both a download and its publicly displayed checksum, comparing those two values offers limited protection. Use a digest obtained through a trusted channel or verify a digital signature when provenance matters.

3. Encryption depends on key management

Even strong encryption can fail if keys are exposed. Plan for key generation, access controls, secure storage, rotation where appropriate, backup, and destruction. Use established KMS or HSM capabilities when warranted.

4. Prefer authenticated encryption

AEAD schemes such as AES-GCM and ChaCha20-Poly1305 protect confidentiality and also detect unauthorized modifications. Follow the specification’s nonce/IV requirements and always verify authentication tags before accepting decrypted data. In particular, do not reuse an AES-GCM nonce with the same key.

5. Avoid designing your own cryptography

Use maintained cryptographic libraries and framework APIs rather than inventing encryption formats, password hashing functions, or custom combinations of primitives.

Which approach should you use?

Requirement	Recommended approach
Store passwords for login verification	Argon2id or another established password hashing scheme
Check that a file has not changed	SHA-256 or another secure cryptographic hash
Verify the publisher or signer of a file	Digital signatures with an appropriate hash function
Protect data confidentiality	Encryption with suitable key management
Protect confidentiality and detect tampering	Authenticated encryption such as AES-GCM; use HMAC where message authentication without encryption is required

Summary

Hashing is a one-way operation that supports integrity checking and secure verification workflows.
Encryption protects confidentiality while allowing authorized decryption with the appropriate key.
SHA-256 is not a password storage scheme. Use an intentionally expensive password hashing method such as Argon2id instead.
Real-world security depends on proper algorithm selection, key management, nonce handling, and authentication, not algorithm names alone.