Hashing gets confused with encryption constantly, including by people who should know better. The difference is not subtle: encryption is designed to be reversed by whoever holds the key, and hashing is designed so that nobody can reverse it at all.

Generate a digest with the Hash Generator — it uses the Web Crypto API in your browser, so nothing you enter is transmitted.

What a hash function does

It takes input of any size and produces a fixed-length output. SHA-256 always gives you 256 bits — 64 hex characters — whether you feed it one letter or a gigabyte file.

Three properties make it useful:

  • Deterministic. The same input always produces the same digest.
  • One-way. Given the digest, there is no practical route back to the input.
  • Avalanche effect. Change one bit of input and roughly half the output bits flip.

That last one is worth seeing rather than reading about. Hash bitcops and then bitcopt — one letter apart — and the two digests share no visible resemblance. That is what makes hashes useful for detecting tampering: any change at all produces a completely different result.

What hashing is genuinely for

Integrity checking. A project publishes the SHA-256 of a download. You hash your copy and compare. If they match, your file is byte-identical to what they published — no corruption, no tampering in transit.

Deduplication. Two files with the same digest are the same file. Storage systems use this constantly.

Digital signatures. Signing a whole document is slow, so you sign its hash instead. The signature covers the digest, and the digest covers the document.

Password storage — but not with these functions. That deserves its own section, because it is where the serious mistakes happen.

Do not hash passwords with SHA-256

This is the most consequential misunderstanding in the whole topic.

SHA-256 is designed to be fast. That is a virtue for verifying a large file and a disaster for storing passwords, because fast means an attacker with a leaked database can try billions of candidates per second on commodity hardware.

Password storage needs a function that is deliberately slow and memory-hungry:

  • bcrypt — mature, well understood, with a tunable cost factor.
  • scrypt — memory-hard, which frustrates GPU cracking.
  • Argon2 — the current recommendation, memory-hard and tunable.

These also salt automatically. A salt is random data mixed into each password before hashing, so two users with the same password get different digests — which is what defeats rainbow tables and stops one cracked password revealing every account that shares it.

If you are reviewing a system and find sha256(password) in the login code, that is a finding worth writing up, even though the hashes are technically "hashed".

MD5 and SHA-1

Both are broken for security purposes, in a specific way: it is practical to construct two different inputs that produce the same digest. That is a collision, and it destroys any use of the hash as proof of integrity, because an attacker can craft a malicious file matching a legitimate file's digest.

MD5 has been broken since the mid-2000s. SHA-1 collisions were demonstrated in practice in 2017, and browsers dropped SHA-1 certificates.

You will still meet both. As non-security checksums — spotting accidental disk corruption — they are fine. As anything a determined attacker might target, they are not. If a system uses MD5 to verify downloads or sign anything, that is worth flagging.

Which to use

SHA-256 for general integrity work. Widely supported, no practical attacks, fast.

SHA-384 or SHA-512 when you want more margin. On 64-bit hardware SHA-512 is often faster than SHA-256, which surprises people.

Argon2 or bcrypt for passwords. Never a general-purpose hash.

HMAC when you need to prove a message came from someone holding a shared key. A plain hash proves the content is unchanged; it proves nothing about who produced it, because anyone can compute a hash.

Verifying a download

  1. Find the publisher's SHA-256 for the file, ideally on a page served over HTTPS.
  2. Hash your copy — sha256sum file on Linux, Get-FileHash in PowerShell, or the Hash Generator for smaller files.
  3. Compare the full string, not the first few characters.

Worth being honest about the limit here: if an attacker controls the page you got the file from, they also control the published hash. Matching digests proves the file matches what that page claimed — not that the page is trustworthy. Checksums protect against corruption and interception, not against a compromised source.

Common questions

Can a hash be reversed?
Not directly. But short or common inputs can be found by guessing and comparing, which is why unsalted password hashes fall so easily.

Is hashing the same as encryption?
No. Encryption is reversible with a key. Hashing is one-way by design.

Why not SHA-256 for passwords?
Too fast. Use Argon2, bcrypt or scrypt — deliberately slow and memory-hard.

Is MD5 still usable?
Only as a non-security checksum. Collisions are practical, so it proves nothing against an attacker.

Where to go next