A hash function takes any input — a single letter, a 4 GB disk image, an empty file — and returns a fixed-length string called a digest. The same input always gives the same digest. A different input gives a completely different one. And there is no way to run the function backwards to get the input out again. That is the whole idea: a short, stable fingerprint that identifies data without containing it.
Feed the word hash to SHA-256 and you get 64 hex characters. Feed it the complete works of Shakespeare and you get 64 hex characters. Feed it nothing at all and you still get 64 hex characters, all different from each other.
What makes a hash function different from any other function
Five properties, and the last two are the ones that separate a cryptographic hash from a cheap one:
- Deterministic. The same bytes always produce the same digest, on any machine, in any language, in any year. No randomness, no timestamp, no salt hidden inside.
- Fixed length. SHA-256 returns 256 bits — 32 bytes, written as 64 hex characters — whether the input was one byte or a gigabyte.
- Avalanche. Change one bit of the input and roughly half the output bits flip. The digests of hash and Hash have nothing visible in common. There is no "close", no partial match, no sorting digests to find similar files.
- One-way. Given a digest, there is no known method of finding an input that produces it other than guessing inputs and hashing them.
- Collision-resistant. Nobody should be able to construct two different inputs that share a digest.
The avalanche property is easier to believe once you watch it. Type a sentence into the hash generator here, change one letter, and every digest on the page is replaced wholesale. The five algorithms disagree with each other completely too, which is worth seeing before you spend an afternoon wondering why your checksum does not match someone else's.
Why two files can share a hash, and why that is fine
There are infinitely many possible inputs and exactly 2256 possible SHA-256 digests. Collisions are not a flaw in the design; they are a mathematical certainty. The security claim is narrower and stranger: collisions exist, and nobody can find one.
For SHA-256 the relevant figure is not 2256 but roughly 2128, the point at which the birthday problem gives you an even chance of two random digests colliding. That is about 340 undecillion attempts. It is not a number anyone gets to.
What matters practically is the difference between two kinds of break. A collision means an attacker builds two inputs with the same digest and gets to choose both — useful for slipping a second document past a signature. A preimage means they start from a digest you already have and find something that matches it. Collisions are far easier to find, which is why MD5 and SHA-1 fell to collision attacks long before anyone got near a preimage on either.
What people actually use hashes for
- Checking a file arrived intact. Hash the download, compare it to the checksum on the project's page, and a truncated transfer or a bad mirror shows up immediately.
- Naming content by what it is. Git identifies every commit, tree and file by its digest, so two identical files are automatically one object. Backup systems and CDN cache keys work the same way.
- Proving you knew something earlier. Publish the hash of your answer now, reveal the answer later, and anyone can check you did not change it in between. That is the honest way to run a prize draw in public — the mechanics are in how to pick a random winner fairly.
- Authenticating a message. HMAC combines a hash with a shared secret so the recipient can tell the message was not altered and came from someone holding the key. The six-digit codes in your authenticator app are HMAC output truncated to six digits, which is why those 2FA codes change every thirty seconds without the app talking to anything.
Separately, the "hash" in hash table means something related but much weaker. Those functions exist to spread keys evenly across buckets fast, and they are trivially reversible by design. Never reach for one where you need the cryptographic guarantees above, and never reach for SHA-256 to index a dictionary.
What a hash is not
It is not encryption
Encryption is a round trip: a key turns plaintext into ciphertext and the same key turns it back. Hashing has no key and no way back. The digest of a 4 GB file is 32 bytes, so almost all of the information has been thrown away rather than hidden. If you need to read the data again later, you wanted encryption with a passphrase, not a digest. People who "hash" a message to send it privately have simply destroyed it.
It does not make small, predictable data private
Hashing an email address, a phone number or a national ID number anonymises nothing. The attacker does not need to reverse anything — they hash every possible value and look up yours. There are only so many phone numbers. Precomputed tables make it cheaper still. A hash only hides an input that was unguessable to begin with.
It is the wrong tool for storing passwords on its own
A plain SHA-256 of a password is fast to compute, which is exactly the problem: a modern GPU tries billions of candidates per second. Password storage needs a per-user salt so one table cannot attack every account at once, and a function deliberately built to be slow. bcrypt, scrypt and Argon2 — the latter chosen by the Password Hashing Competition in 2015 — are the ones to use. None of the five algorithms in the tool above belongs anywhere near a password database.
Which algorithm should you use?
| Algorithm | Digest | Verdict |
|---|---|---|
| SHA-256 | 64 hex chars | The default. No practical attack known. |
| SHA-512 | 128 hex chars | Same family, 64-bit words. Often faster on 64-bit hardware. |
| SHA-3 | varies | A different internal design, standardised in 2015. Insurance, not an upgrade. |
| SHA-1 | 40 hex chars | Collisions demonstrated by CWI Amsterdam and Google in 2017. Not for signatures. |
| MD5 | 32 hex chars | Collisions since 2004, seconds on a laptop. Legacy checksums only. |
Pick SHA-256 unless something else forces your hand. NIST announced in December 2022 that SHA-1 should be out of use by the end of 2030, and the deadline is generous — it has been unfit for signatures for years. MD5 and SHA-1 still catch a corrupted download, because nobody has a practical preimage attack on either, and they still offer no protection against someone who controlled the file from the start.
What a matching checksum actually proves
It proves the bytes you have are the bytes whoever published that checksum was describing. That is less than it sounds. If the download link and the checksum sit on the same page, an attacker who replaced the file replaced the number underneath it in the same edit. You have verified the file against itself.
Real authenticity needs a signature: a digest signed with a key you already trust, checked with something like gpg --verify. The hash is still doing the work in there — signing 32 bytes is cheap where signing a gigabyte is not — but the trust comes from the key, not the digest. A bare checksum is a consistency check. Treat it as one and it is genuinely useful.
If you want to see any of this rather than take it on faith, the hash generator produces all five digests at once for text or a file, and takes a published checksum to compare against so you are not reading 64 hex characters off two screens. Nothing is uploaded — the file is read and hashed on your own machine.
The one-way property only holds when the input was unguessable, which turns "can this hash be reversed" into an entirely different question about how many candidates an attacker can try. How long it would take to crack your password works through the arithmetic, and the spread between the best and worst case is wider than most people expect.
Frequently asked questions
What is a hash function in simple terms?
It is a function that turns any amount of data into a short, fixed-length string called a digest. The same input always gives the same digest, and changing one character of the input changes the whole digest. You cannot work backwards from the digest to the original data.
What is the difference between hashing and encryption?
Encryption is reversible: a key turns the data into ciphertext and turns it back again. Hashing is one-way and has no key, so the original data cannot be recovered at all. Use encryption when you need to read the data later, and hashing when you only need to check whether two things are identical.
Can a hash be reversed?
Not directly. A digest is the same size no matter how large the input was, so most of the information no longer exists. Lookup sites appear to reverse hashes by hashing billions of likely inputs in advance and searching for a match, which works against short or common values and fails completely against long random ones.
Which hash algorithm should I use?
SHA-256 unless you have a specific reason not to. It is fast, available in every language and browser, and has no practical attack against it. SHA-512 is a reasonable alternative and is often quicker on 64-bit hardware despite the longer output.
Why is MD5 not safe anymore?
Two different files can be crafted to produce the same MD5 digest in seconds on ordinary hardware, a technique published in 2004. That breaks any use where a digest stands in for a document, such as a signature. MD5 still detects an accidentally corrupted download, because finding an input for a digest you did not choose remains impractical.
Is it safe to hash passwords with SHA-256?
No. SHA-256 is built to be fast, and a graphics card can test billions of guesses per second against it. Password storage needs a per-user salt and a deliberately slow function such as bcrypt, scrypt or Argon2.
Last updated September 19, 2026