The short answer
Encryption scrambles data so that only someone with the key can turn it back: it's reversible by design. Hashing turns data into a fixed-length fingerprint that can't be turned back into the data, with or without a key. Use encryption to keep something secret and get it back later; use hashing to check something without keeping it, such as a password or a file's integrity.
See both on your own text
Type in the box. The hash changes completely with every letter, and stays the same length. The encrypted text can only be turned back with the password, and decrypting it gives your text exactly.
Side by side
| Encryption | Hashing | |
|---|---|---|
| Purpose | Keep data secret, then read it again | Check or identify data without storing it |
| Reversible? | Yes, with the key | No |
| Key | Needed to encrypt and to decrypt | None (a salt or HMAC key is a different thing) |
| Output length | Grows with the input | Always the same, whatever the input |
| Same input twice | Usually different output (random IV) | Always the same output |
| Typical uses | HTTPS, disk encryption, messaging | Password storage, checksums, Git, signatures |
| Examples | AES, ChaCha20, RSA | SHA-256, SHA-3, BLAKE2; bcrypt and Argon2 for passwords |
The avalanche effect
Change one letter, Hello to Jello, and about half the bits of a good hash flip. That's why a hash can't be nudged towards a target: nothing about the output tells you how close the input was.
For comparison, SHA-256 of Hello is `185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969` and of Jello is `2c5cccf620a95c8f5d20dceb7ec4ab6b6225319b215e9c00f697caeb9ae79a1b`. One letter apart, and nothing in common.
Why passwords are hashed, not encrypted
A site never needs to know your password, only that what you typed matches. So it stores a hash, and on login hashes what you type and compares the two. If the database leaks, there's no key that turns the hashes back into passwords. An encrypted password store is weaker: whoever gets the key gets every password.
Plain SHA-256 or MD5 isn't enough, though. They're built to be fast, which lets an attacker try billions of guesses a second against a leaked hash. Password storage uses deliberately slow functions with a salt, a random value stored with each hash so identical passwords get different hashes. OWASP's current advice is Argon2id, with bcrypt or scrypt as alternatives and PBKDF2 where FIPS-140 compliance is needed.
About the encryption demo
The demo uses AES-256-GCM through your browser's Web Crypto API, with the key made from the password by PBKDF2 (600,000 rounds) and a random salt and IV. It's there to show the difference, not to protect anything: for real secrets, use an established tool. Nothing you type, password included, leaves the page.
Questions
Is hashing more secure than encryption?
Neither is more secure; they do different jobs. Encryption is for data you need back. Hashing is for data you only need to check.
Can a hash be decrypted?
No. There's no key. The only attack is guessing inputs and comparing hashes, which is why weak passwords and fast hashes are a risk.
Is SHA-256 encryption?
No. SHA-256 is a hash function: one-way, fixed-length, with no key.
What's a salt?
A random value stored next to each password hash and mixed into it, so two people with the same password get different hashes and precomputed tables don't work.
Sources
Added . What's new