Cryptography

Hashing vs Encryption: The Difference That Confuses Everyone

7 min read
By
Hashing vs Encryption: The Difference That Confuses Everyone

Photo by Lukas from Pexels

Here is a sentence I see all the time: "I encrypted my password with bcrypt." It sounds reasonable. It is also completely wrong.

The confusion between hashing and encryption is one of the most common misunderstandings in security. It is not just a terminology issue. It reflects a fundamental misunderstanding of what these two operations do, and that misunderstanding leads to real security mistakes.

Let's clear this up.

What Hashing Is

A hash function takes an input of any size and produces a fixed-size output. The same input always produces the same output. Different inputs should produce different outputs. And crucially, the process is one-way: you cannot reverse it.

Think of a hash function as a meat grinder. You put a steak in, and you get ground beef out. There is no machine that turns ground beef back into a steak. The transformation is permanent.

SHA-256 is a hash function. You feed it "hello" and it gives you a 64-character hexadecimal string. You feed it "hello" again and it gives you the same string. You feed it "hello world" and it gives you a completely different string. There is no key, no decryption, no way to get back from the output to the input.

Hashing is deterministic (same input always gives same output), one-way (you cannot reverse it), and collision-resistant (it is computationally infeasible to find two different inputs that produce the same output).

What Encryption Is

Encryption also transforms data, but it is a two-way operation. You encrypt plaintext with a key to get ciphertext. You decrypt ciphertext with the same key to get back the plaintext. The transformation is reversible.

AES-256-GCM is an encryption algorithm. You encrypt "hello" with a key and get ciphertext. You decrypt that ciphertext with the same key and get "hello" back. Without the key, you cannot decrypt.

Encryption is reversible (with the key), key-dependent (different keys produce different ciphertexts), and in the case of authenticated encryption like GCM, integrity-protected (tampering is detected).

The Key Difference

The fundamental difference is reversibility. Hashing is one-way. Encryption is two-way. Everything else follows from this.

If you hash a password, you cannot recover it. You can only verify it by hashing a candidate password and checking if the output matches. This is why websites can verify your password without storing it: they store the hash, and when you log in, they hash what you typed and compare.

If you encrypt a password, you can recover it. You just need the key. This is why you should never encrypt passwords for storage: if your key is compromised, every password is exposed. Hashing is the correct approach for password storage.

If you encrypt a file, you can recover it with the key. This is what you want for data you need to use later. You encrypt a document, store the ciphertext, and decrypt it when you need to read it. Hashing would be useless here because you could never get the document back.

When to Use Each

The decision is simple. If you need to recover the original data later, use encryption. If you only need to verify the data, use hashing.

**Use hashing for:** - Password storage. You hash passwords with bcrypt or Argon2. You never need to recover the password, only verify it. - File integrity. You hash a file and store the hash. Later, you hash the file again and check if the hash matches. If it does, the file has not been modified. - Digital signatures. You hash a document and sign the hash. The recipient hashes the document and verifies the signature against the hash. - Content addressing. Systems like Git use hashes to identify commits, files, and trees.

**Use encryption for:** - Protecting files. You encrypt a file so only someone with the key can read it. - Securing messages. You encrypt a message so only the intended recipient can read it. - Encrypting database columns. You encrypt sensitive data like credit card numbers so it can be recovered when needed. - VPN and TLS. You encrypt network traffic so intermediaries cannot read it.

Why You Cannot "Decrypt" a Hash

This is the question that reveals the confusion. People ask: "If I know the hash, can I decrypt it to get the original password?"

The answer is no, and the reason is not that it is hard. The reason is that the information is not there. A hash is not an encoding of the input. It is a fingerprint of the input. Just as you cannot reconstruct a person from their fingerprint, you cannot reconstruct the input from its hash.

SHA-256 takes any input and produces a 256-bit output. There are infinitely many inputs that map to the same 256-bit output (this is the pigeonhole principle). The hash function is designed so that finding any of those inputs is computationally infeasible, but they exist. This means there is no unique "decryption" of a hash. Even if you could reverse the function (which you cannot), you would not know which of the many possible inputs was the original.

The only way to "crack" a hash is to try inputs one at a time, hash them, and see if the output matches. This is brute-forcing, and for a well-chosen password hashed with bcrypt or Argon2, it is computationally infeasible.

The Password Hashing Exception

There is a special category of hash functions designed specifically for passwords: bcrypt, scrypt, Argon2. These are still one-way hash functions, but they are deliberately slow and (in the case of scrypt and Argon2) memory-hard.

General-purpose hash functions like SHA-256 are designed to be fast. This is great for file integrity (you want to hash a 10GB file quickly) but terrible for passwords (an attacker can try billions of guesses per second). Password hashing functions trade speed for security, making each hash computation take a meaningful amount of time.

This is why you should use bcrypt or Argon2 for password storage, not SHA-256. We cover this in detail in our PBKDF2 vs bcrypt vs Argon2 comparison. And for a deeper look at how bcrypt works, see our bcrypt explained post.

The Bottom Line

Hashing is one-way. Encryption is two-way. That is the whole story. If you need the data back, encrypt it. If you only need to verify it, hash it. And never, ever say you "encrypted" a password when you hashed it. The words matter because the operations are fundamentally different, and using the wrong one leads to security vulnerabilities.

If you want to see encryption in action, try our AES text encryptor. If you want to see password hashing, try our bcrypt generator. The difference will be immediately obvious: the encryptor lets you decrypt, the bcrypt generator does not.

Frequently Asked Questions

Can you decrypt a hash?

No. Hashing is a one-way function. There is no decryption key and no algorithm to reverse a hash back to its input. The only way to "crack" a hash is to try different inputs, hash them, and see if the output matches. This is called brute-forcing, and a good hash function makes it computationally infeasible for strong inputs.

Is a password hash the same as encrypted password?

No. When a website stores your password, it hashes it (using bcrypt, Argon2, or similar). The hash cannot be reversed to recover the password. When you log in, the site hashes the password you entered and compares it to the stored hash. Encryption, by contrast, is reversible with the right key. Calling a password hash "encrypted" is a common but incorrect usage.

When should I use hashing and when should I use encryption?

Use hashing when you need to verify data without storing it: password storage, file integrity checks, digital signatures. Use encryption when you need to recover the original data later: protecting files, securing messages, encrypting database columns. The rule of thumb: if you need to get the data back, use encryption. If you only need to verify it, use hashing.

Why are hash functions like SHA-256 not suitable for password hashing?

SHA-256 is designed to be fast, which makes it bad for passwords. An attacker with a GPU can compute billions of SHA-256 hashes per second, making brute-force password cracking trivial. Password hashing functions like bcrypt and Argon2 are deliberately slow, making the same attack take years instead of seconds. Use SHA-256 for data integrity, not for passwords.

Try NovelCrypt Tools

Experience military-grade encryption for your sensitive data. Create self-destructing messages, encrypt files, or explore our experimental lab tools.

Explore NovelCrypt