Here is the one-sentence version, and it is the only thing you really have to remember: 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.
Encryption: scrambling you can undo
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, 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. 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.
Hashing: a fingerprint that only goes one way
A hash function takes any input, a word, a file, a whole database, and produces a fixed-length string called a digest. 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, 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, the file is byte-for-byte identical 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.
Why passwords are hashed, not 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, not a read, so hashing fits perfectly.
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 random value mixed into each password before hashing, so two people with the same password get different digests and attackers cannot precompute a giant lookup table. And modern password hashes (bcrypt, scrypt, Argon2) 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 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 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. Keep the one-way versus two-way split straight and the rest follows.
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.