---
title: Hashing vs Encryption: What's the Difference? | Relic
description: Hashing vs encryption comes down to one thing: only encryption is meant to be reversed. The difference in plain English, and why passwords are hashed.
canonical: https://relic.space/blog/hashing-vs-encryption
source: https://relic.space/llms.txt
---
[Developer copy and paste](https://relic.space/blog/topics/dev-toolbox)

# Hashing vs encryption: what is the difference?

Hashing and encryption both scramble data, so the words get swapped around constantly. But they solve opposite problems: one is meant to be undone, the other never is. Get the distinction right and a lot of security questions suddenly answer themselves.

[JGJordan Gibbs](https://relic.space/authors/jordan-gibbs) June 29, 2026 7 min readUpdated September 12, 2026

## What is the difference between hashing and encryption?

**Encryption is reversible, hashing is not**. Encryption locks data so the right key can unlock it again. Hashing crushes data into a fixed-length fingerprint that nobody can turn back into the original, on purpose. They both look like “scrambling,” which is why people mix them up, but they exist for different jobs.

Once that click happens, the follow-up questions sort themselves out. Why do passwords get hashed but messages get encrypted? Why can a website check your password without ever knowing it? Why is a file checksum not a secret? All of it comes back to that single split between one-way and two-way.

## What does encryption actually do?

Encryption takes readable data, the plaintext, and uses a key plus an algorithm to turn it into ciphertext that looks like noise. The whole point is that the process runs in reverse. Feed the ciphertext and the correct key back through, and you get the original data out, exact to the byte.

That two-way design is what makes encryption right for anything you need to read later: messages, files, backups, the contents of your notes. The security rests entirely on the key. If you hold the key and nobody else does, the data is private even if the encrypted blob is stolen, because without the key it is just noise. This is the foundation of [end-to-end encryption](https://relic.space/blog/what-is-end-to-end-encryption), where the data is locked on your device and only you carry the key.

There are two broad flavours. **Symmetric** encryption uses the same key to lock and unlock, which is fast and good for data at rest. The standard here is [AES, which comes in 128-bit, 192-bit and 256-bit key sizes](https://csrc.nist.gov/pubs/fips/197/final), and [OWASP says to use at least 128 bits and ideally 256](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic%5FStorage%5FCheat%5FSheet.html). **Asymmetric** encryption uses a public key to lock and a private key to unlock, which is how secure messaging and HTTPS exchange secrets without ever sharing the unlock key. Different mechanics, same core promise: what gets locked can be unlocked again by whoever holds the right key.

## What does hashing actually do?

A hash function takes any input, a word, a file, a whole database, and [maps it to a fixed-length message digest](https://csrc.nist.gov/projects/hash-functions). SHA-256 returns 256 bits every time, and the SHA-3 family goes up to 512\. The same input always gives the same digest. Change a single character and the digest changes completely. Critically, there is no unlock step. You cannot run a hash backwards to recover the input, because the function deliberately throws information away. We go deeper on the mechanics in [what is a hash function](https://relic.space/blog/what-is-a-hash-function), but the headline is that hashing is a trapdoor: easy to go in, no way back out.

So what use is a one-way function? Plenty, and it is precisely the one-way nature that makes it useful. A hash lets you prove two things match without keeping the thing itself.

* **Verifying integrity.** Publish the hash of a file. Anyone who downloads it can hash their copy and compare. If the digests match, you have the file the publisher hashed, and nothing was tampered with in transit.
* **Checking passwords without storing them.** A service stores the hash of your password, never the password. When you log in, it hashes what you typed and compares. Match means you are in, and the real password was never on file.
* **Indexing and deduplication.** Systems use hashes as quick fingerprints to tell whether two pieces of content are the same, without comparing every byte each time.

A quick test for which one you want: do you ever need to read this data again? If yes, you need encryption. If you only ever need to check that something matches, hashing is the safer choice, because there is nothing to steal and read back.

## Why are passwords hashed instead of encrypted?

This is the question that makes the difference concrete. A login system never actually needs to know your password. It only needs to confirm that the password you typed now is the same one you set before. That is a match check rather than a read, so hashing fits perfectly. It is also the rule: [OWASP says passwords should be hashed with a modern adaptive algorithm in almost all circumstances](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html), and encrypted only in the rare case where an application genuinely has to recover the original.

Encrypting passwords would be worse. Encryption is reversible, so somewhere there would have to be a key that turns every stored password back into plain text. That key becomes a single jackpot for an attacker: steal it and you unlock every account at once. Hashing has no such key. Even if the entire database leaks, the attacker gets digests, not passwords, and a well-built hash makes guessing them slow and expensive.

Real systems add two refinements. A **salt** is a unique random value mixed into each password before hashing, so two people with the same password get different digests and an attacker has to crack the hashes one at a time instead of precomputing a giant lookup table. And modern password hashes (Argon2id first, then scrypt, with bcrypt for legacy systems) are deliberately _slow_, which barely matters for one honest login but makes mass guessing impractical. If you ever want to see hashing in action, our [hash generator](https://relic.space/tools/hash-generator) runs common algorithms in your browser so you can watch a digest change the instant you tweak the input.

## Common mix-ups, cleared up

### “Encoding” is neither

Base64 and similar schemes are sometimes mistaken for security, but encoding is just a reformat with no secret involved. Anyone can decode it instantly. If you have seen [Base64](https://relic.space/blog/what-is-base64-encoding) in a token or data URL, that is encoding, not encryption, and it protects nothing on its own.

### A hash is not a secret you hide

Hashes are often published openly, which confuses people who assume anything scrambled must be private. A file checksum is meant to be public so others can verify against it. The hash reveals nothing useful about the input, so there is nothing to hide.

### Hashes can still be guessed

One-way does not mean uncrackable. Attackers do not reverse a hash, they guess inputs, hash each guess, and look for a match. Weak passwords and fast, unsalted hashes make that easy, which is the whole reason salts and slow algorithms exist.

## Which one do you need?

* **Encryption** when you have to read the data back later and keep it private in the meantime: messages, files, notes, a clipboard history.
* **Hashing** when you only need to confirm a match or detect a change: passwords, download integrity, deduplication.

Both jobs run quietly under the tools developers touch every day, which is why this piece sits alongside our guide to [copying and pasting in the terminal](https://relic.space/blog/copy-and-paste-in-the-terminal). Keep the one-way versus two-way split straight and the rest follows.

## Sources

* [FIPS 197: Advanced Encryption Standard (AES)](https://csrc.nist.gov/pubs/fips/197/final), NIST (2023)
* [Hash Functions: approved algorithms and security strengths](https://csrc.nist.gov/projects/hash-functions), NIST Computer Security Resource Center
* [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html), OWASP
* [Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic%5FStorage%5FCheat%5FSheet.html), OWASP

## Frequently asked questions

Is hashing the same as encryption?+

No. Encryption is reversible: it scrambles data with a key so that someone with the right key can unscramble it later. Hashing is one-way: it turns any input into a fixed-length fingerprint that cannot be turned back into the original. Encryption keeps secrets you need to read again; hashing proves something matches without storing the thing itself.

Why are passwords hashed instead of encrypted?+

Because the service never needs to read your actual password, it only needs to check that the one you typed matches the one you set. Hashing lets it store a fingerprint instead of the real thing, so a database breach does not hand attackers your password directly. If passwords were encrypted, the key that unlocks them would also be a target, and stealing it would expose every account at once.

Can a hash be reversed or decrypted?+

Not directly. A good hash function is designed so there is no practical way to compute the original input from the output. Attackers instead guess inputs, hash each guess, and look for a match, which is why slow hashes and random salts matter. Encryption, by contrast, is meant to be reversed, but only by whoever holds the key.

JG

Written by

[Jordan Gibbs](https://relic.space/authors/jordan-gibbs)Founder, Relic

Jordan Gibbs is the founder of Relic, an end-to-end encrypted, permanent, searchable memory for everything you copy. He writes widely about AI, agents, and practical tooling on Medium, where he is read by tens of thousands, and builds privacy-first software. Here he covers how everyday tools like the clipboard actually work, and how to use them without handing your data to someone else.

[Medium](https://medium.com/@jordan%5Fgibbs)[GitHub](https://github.com/jordan-gibbs)[LinkedIn](https://www.linkedin.com/in/jordan--gibbs/)

Part of

[Developer copy and paste](https://relic.space/blog/topics/dev-toolbox)
* [How to copy and paste in the terminal· pillar](https://relic.space/blog/copy-and-paste-in-the-terminal)
* [What is a UUID?](https://relic.space/blog/what-is-a-uuid)
* [What is a JWT token?](https://relic.space/blog/what-is-a-jwt-token)
* [What is a hash function?](https://relic.space/blog/what-is-a-hash-function)
* [What is Base64 encoding?](https://relic.space/blog/what-is-base64-encoding)
* [How to copy a file path](https://relic.space/blog/how-to-copy-a-file-path)

Keep reading

[Pillar·13 minHow to copy and paste in the terminalCtrl C cancels a command in the terminal, so copy and paste works differently there. Shortcuts for every terminal, plus SSH, PuTTY, Termius and browser terminals.Read ](https://relic.space/blog/copy-and-paste-in-the-terminal)[7 minWhat is a UUID?A UUID is a 128-bit value designed to be unique without any central authority handing it out. What they are, how the versions differ, and when to reach for one.Read ](https://relic.space/blog/what-is-a-uuid)[7 minWhat is a JWT token?A JWT packs a user's identity into a signed, self-contained token. What the three parts hold, how the signature works, and what a JWT does and does not protect.Read ](https://relic.space/blog/what-is-a-jwt-token)

developerencryptionsecurity