Encryption vs Hashing: What's the Difference?

Encryption and hashing are both ways of transforming data, but they serve completely different purposes — and using one where you should use the other is a serious security mistake. Understanding the distinction will change how you think about every secure system you use or build.

The One-Sentence Version

Everything else flows from that distinction. The question of which to use always comes back to: do you need to recover the original data later? If yes, encrypt it. If no — if you only need to verify that data matches — hash it.

What Is Encryption?

Encryption transforms plaintext (readable data) into ciphertext (scrambled data) using a mathematical algorithm and a key. Anyone with the correct key can reverse the process and recover the original plaintext. The key is what makes it secure: without the right key, the ciphertext is meaningless.

Symmetric Encryption

In symmetric encryption, the same key is used to encrypt and decrypt. The most widely used symmetric algorithm is AES (Advanced Encryption Standard). AES-256 uses a 256-bit key and is currently considered unbreakable with existing technology.

Symmetric encryption is fast and efficient, making it suitable for encrypting large amounts of data — hard drives (BitLocker, FileVault), databases, files at rest, and VPN tunnels all use symmetric encryption for bulk data.

The challenge with symmetric encryption is key distribution: how do you securely share the key with someone who needs to decrypt your data, if the communication channel itself might be compromised? This is where asymmetric encryption comes in.

Asymmetric Encryption

Asymmetric encryption uses a mathematically related key pair: a public key that can encrypt data, and a private key that can decrypt it. Data encrypted with the public key can only be decrypted with the corresponding private key. The public key is freely shared; the private key is kept secret.

RSA and elliptic-curve cryptography (ECC) are the dominant asymmetric algorithms. Asymmetric encryption is computationally expensive, so in practice it is used not for bulk data but for securely exchanging symmetric keys (as in TLS/HTTPS) or for digital signatures.

What Is Hashing?

A hash function takes any input and produces a fixed-length output called a hash or digest. There is no key, and there is no way to reverse the function. The same input always produces the same output (determinism), but there is no mathematical path from the output back to the input.

Common cryptographic hash functions include SHA-256 (256-bit output, currently secure), SHA-3 (modern alternative), and the now-broken MD5 and SHA-1. For password hashing specifically, algorithms like bcrypt, Argon2, and scrypt are used — these are deliberately slow to make brute-force attacks expensive.

Because hashing is one-way, it is used for verification, not retrieval. You can verify that a submitted password matches a stored hash without ever storing or knowing the actual password. You can verify that a file is intact by comparing its current hash to a known-good hash from before.

The Classic Mistake: "Encrypting" Passwords

One of the most common — and costly — security mistakes is storing user passwords using encryption instead of hashing.

The problem: encryption requires a key. If you encrypt passwords, that key is stored somewhere on your servers. If an attacker gains access to both the encrypted password database and the encryption key (which often happens together in a server compromise), they can decrypt every single user's password in seconds. The encryption provided no meaningful protection against the actual threat.

With hashing, there is no key for an attacker to steal. The stored value is a one-way transformation. An attacker who steals a database of properly hashed passwords must then brute-force each hash individually — a slow, expensive process, especially if the passwords were hashed with bcrypt or Argon2 which are designed to be computationally intensive.

This is why the security industry is unambiguous: passwords must be hashed, never encrypted. High-profile breaches of companies like Adobe (2013, 153 million accounts) and LinkedIn (2012, 117 million accounts) were particularly damaging precisely because Adobe used symmetric encryption (with the same key for all users) and LinkedIn used unsalted MD5 — both fundamentally wrong approaches.

When to Use Encryption

Use encryption when you need to store or transmit data that must be recovered in its original form by an authorized party:

• Data in transit: TLS/HTTPS encrypts web traffic between your browser and servers. Without it, anyone on the same network can read your data in plain text.
• Data at rest: Full-disk encryption (BitLocker, FileVault) encrypts your hard drive. If your laptop is stolen, the data is unreadable without the decryption key.
• Sensitive records: Medical records, financial data, private messages, or any personal data that must be stored but also retrieved need encryption.
• Key exchange: Asymmetric encryption is used in TLS to securely agree on a symmetric session key at the start of an HTTPS connection.
• Password managers: The vault (your stored passwords) is encrypted with a key derived from your master password. Unlike password hashing, you need to retrieve those passwords — so encryption is correct here.

When to Use Hashing

Use hashing when you only need to verify that data matches, without ever needing to recover the original:

• Password verification: Store the hash, verify by hashing what the user submits and comparing.
• File integrity: Download a file, hash it, compare to the publisher's stated hash to detect tampering or corruption.
• Data deduplication: Hash files to detect duplicates without comparing entire files byte-by-byte.
• Digital signatures: Hash the document, then sign the hash. Verifiers hash the document again and compare — an efficient way to detect any change to the document.
• API tokens and session IDs: Store hashes of tokens/sessions so that even if the database is stolen, the tokens cannot be used without the original values.

Digital Signatures: Where Both Are Used Together

Digital signatures are a compelling example of encryption and hashing working together. To sign a document:

1. Hash the document with SHA-256 (produces a 64-character fingerprint)
2. Encrypt that hash with your private key (the signature)
3. Attach the signature to the document

To verify the signature:

1. Decrypt the signature with the signer's public key (reveals the original hash)
2. Hash the received document independently
3. If the two hashes match, the document is authentic and unmodified

Hashing makes signing efficient (you only sign a short hash, not the full document). Asymmetric encryption makes authentication possible (only the private key holder could have produced a signature that decrypts correctly with the public key). TLS, code signing, email signing (S/MIME, PGP), and document signing all use this combined approach.

The Bottom Line

Encryption and hashing solve different problems. Encryption is for confidentiality when the original data needs to be recovered — use it for stored data, transmitted data, and secret key exchange. Hashing is for integrity and verification when the original data does not need to be recovered — use it for passwords, file checksums, and digital signatures. Using encryption where hashing is correct (passwords) is a critical security vulnerability. Keep the distinction clear and choose the right tool for the job.