A hash turns any input into a fixed-length fingerprint. The same input always gives the same output, a one-character change gives a completely different one, and there is no way back. That last property is what separates it from encryption: encryption is reversible with a key, hashing is not reversible with anything, and calling a hash "encrypted" describes the wrong operation entirely.
SHA-256 produces a 256-bit digest written as 64 hexadecimal characters, and it is the default choice for essentially everything that needs a hash today.
Which hash for which job?
The choice depends entirely on why you are hashing.
| Purpose | Use | Why |
|---|---|---|
| Anything security-related | SHA-256 or SHA-512 | Collision-resistant, current |
| Verifying a download | Whatever the publisher published | Comparison, not security |
| Detecting duplicate files | Any of them | Speed matters more than strength |
| Storing passwords | None of these | Use a password hash: bcrypt, scrypt, Argon2 |
That last row is the one that matters most and is most often got wrong. General-purpose hashes are designed to be fast, which is exactly the wrong property for storing a password — a fast hash lets an attacker try billions of guesses a second. Password hashes are deliberately slow and salted, and they are a different family of function.
Is MD5 useless?
No, and it is worth being precise about what "broken" means. MD5 has been cryptographically broken since 2004, and what is broken is collision resistance: an attacker can construct two different inputs with the same digest.
That destroys it for signatures and certificates, where an attacker chooses both documents. It does not destroy it for detecting accidental corruption or for finding duplicate files, where nobody is trying to fool you and the inputs are not attacker-controlled.
The practical rule is that MD5 is fine as a fast checksum and unacceptable as a security primitive. Where a publisher offers both, take the SHA-256.
Why must a checksum be computed locally?
Not for privacy — for logic. Uploading a file to a website so that it can tell you the file is genuine asks the thing you are verifying against to also be the thing doing the verifying.
If the file were tampered with in transit, a service that received the tampered copy would happily hash the tampered copy. The comparison only means something when your machine computes the hash of the bytes you actually hold and you compare it against a value obtained separately, from the publisher.
That is why checksum verification belongs in the browser or on the command line and never on a server that received the file first.
What can a hash answer that a filename cannot?
Whether two files are the same file. Identical hashes mean identical bytes, so hashing settles questions filenames cannot: did this copy survive the transfer intact, are these two downloads the same build, is this a duplicate under a different name.
For finding duplicates at scale the size column does most of the work first — files of different sizes cannot be identical, so scanning for matching sizes and only hashing within those groups is dramatically faster than hashing everything.
The avalanche property is what makes this reliable. Changing one bit of the input changes about half the bits of the output, so near-identical files produce completely unrelated hashes and there is no notion of two hashes being "close".
Two things that look like exceptions are worth naming. A hash of a very small input space — a phone number, a postcode, a national ID — is effectively reversible by trying every possibility, so hashing does not anonymise data drawn from a short list. And a hash of a file reveals whether you hold a specific known file, which is how content-matching systems work and why "we only store hashes" is not always the privacy claim it sounds like.
What does a hash not tell you?
Anything about the content, deliberately. A digest carries no information about length, type or meaning — that is what makes it safe to publish and useless as a summary.
It also says nothing about authenticity on its own. A hash published on the same compromised page as the file it describes verifies nothing, which is why signatures exist: they bind the hash to an identity with a key, and that is the property a checksum alone lacks.
Questions people ask
Can a hash be reversed? Not by computation. Short or common inputs can be found by looking them up in a precomputed table, which is why salting exists — it makes every stored password a distinct problem.
Do collisions matter for file checking? Not for accidental corruption. A random change producing a matching SHA-256 is so improbable it can be discounted; a deliberate one against MD5 cannot.
Why 64 characters for SHA-256? Because 256 bits is 32 bytes, and each byte is two hex characters. SHA-512 gives 128 characters by the same arithmetic.
Is SHA-1 still usable? For non-security uses, and it should be treated as MD5 is: fine for corruption checks, unacceptable for signatures. Practical collisions were demonstrated in 2017.
One-way by design, and that is the feature rather than a limitation. The hash generator covers the algorithms side by side, SHA-256 and MD5 handle the two you will meet most, and the checksum calculator and file hash checker do the comparison locally, which is the only place it means anything.