Home · Blog · What is a hash

What a hash function actually does (and what it doesn't)

11 Oct 2026 · Security · 7 min read

You've probably seen strings like ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad next to software downloads, labelled "SHA-256". That 64-character string is a hash — a fingerprint of the file. Change one byte of the file and the fingerprint changes completely. Hash functions are among the most quietly useful tools in computing, and also among the most misunderstood.

The confusion usually comes in two flavours: people think hashing is a kind of encryption (it isn't), or they think a hash is just a checksum with a fancier name (it's related, but the differences matter enormously). This article explains what hash functions do, the properties that make them special, what they're actually used for, and the mistakes people make with them.

The basic idea: fingerprints for data

A hash function takes input of any size — a single word, a novel, a 4 GB video file — and produces a fixed-size output called a digest. SHA-256, the most common one you'll meet, always produces 256 bits, usually written as 64 hexadecimal characters. The same input always produces the same digest, on every computer, every time. That's the determinism property, and it's what makes hashes useful as identifiers.

Try it yourself: the SHA-256 of abc is always ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. The SHA-256 of abd — one letter different — is a52d159f262a45f74d2da3dd409d0d7b2d49844c0d7b2d8b9b9e5f8a5f5f5e0... well, not exactly that, but you get the idea: completely different, with no visible relationship to the first. This is the avalanche effect — a tiny change in input scrambles the output entirely — and it's deliberate. It means you can't learn anything about the input from the digest, and you can't predict how a change will affect it.

Crucially, the process is one-way. Given the digest, there is no practical way to reconstruct the input. You can't "decrypt" a hash because nothing was encrypted — the original data was never stored in the output in any recoverable form. The only way to find an input matching a digest is to guess inputs and hash them until one matches, which for a 256-bit digest means searching a space of 2²⁵⁶ possibilities. To put that in perspective: even if every atom in the observable universe were a computer guessing a billion times per second since the Big Bang, you'd still be nowhere close.

What makes a hash function "cryptographic"

Not every hash function is suitable for security work. Your programming language's built-in hash table uses a hash function too, but it's designed for speed, not safety. A cryptographic hash function needs three properties:

• Pre-image resistance: given a digest, you can't find any input that produces it (the one-way property above).
• Second pre-image resistance: given an input and its digest, you can't find a different input with the same digest. This is what stops someone swapping a file while keeping its fingerprint.
• Collision resistance: you can't find any two different inputs with the same digest. This is the strongest requirement, and it's the one that breaks first when a hash function ages.

That last property is why MD5 and SHA-1 are retired for security purposes. Both are "broken" in the specific sense that researchers have demonstrated practical collision attacks — two different files with the same MD5 digest. The famous 2017 SHAttered attack produced two different PDFs with the same SHA-1 hash. The digests still look random and the functions still work as fingerprints for non-adversarial uses, but anything where an attacker benefits from a collision — digital signatures, certificates — must use SHA-256 or better.

What hashes are actually for

Verifying downloads. This is the use you've already seen. A software vendor publishes a file and its SHA-256 digest. You download the file, hash it locally, and compare. If the digests match, the file arrived byte-for-byte intact — no corruption in transit, no tampering. Note the subtlety: you're trusting the digest's source. If an attacker can replace the file, they can usually replace the published digest too, which is why digests are ideally fetched over a separate trusted channel or signed.

Data integrity in systems. Version control (Git identifies every commit by a SHA-1 hash, now transitioning to SHA-256), deduplication in storage systems, and blockchain structures all use hashes as content addresses: the identifier is derived from the content, so identical content always has the identical identifier, and any change is automatically detectable.

Password storage — with a big asterisk. Systems never store your password; they store a hash of it, then compare hashes at login. But plain fast hashes like SHA-256 are the wrong tool here, because attackers with a stolen database can guess billions of passwords per second. Proper password storage uses deliberately slow, salted functions — bcrypt, scrypt or Argon2 — designed to make each guess expensive. A fast hash function on a login page is a design flaw, not a best practice. (Salting, briefly: a unique random value mixed into each password before hashing, so identical passwords get different digests and precomputed "rainbow tables" become useless.)

Commitments and fingerprints. Anywhere you need to bind yourself to data without revealing it yet — sealed bids, for instance — a hash works as a commitment: publish the digest now, reveal the data later, and everyone can verify the data matches the commitment.

Hash vs checksum: what's the difference?

People often use "hash" and "checksum" interchangeably, and for casual purposes the difference rarely matters — but it's worth knowing. A checksum (like CRC32) is designed to catch accidental corruption: flipped bits in transit, truncated downloads. It's fast and simple, and that's enough when nobody is trying to fool you. A cryptographic hash is designed to survive an adversary: someone deliberately crafting a different file with the same fingerprint. Checksums make no such promise — it's trivial to construct two files with the same CRC32. So the rule is: checksums for accidents, cryptographic hashes for attackers. And when a download page offers both MD5 and SHA-256 digests, the MD5 is legacy baggage — verify against the SHA-256 and ignore the MD5.

What hashing is not

It is not encryption. Encryption is reversible with the right key; hashing is reversible by nobody. People sometimes "hash" sensitive data thinking they've encrypted it, then discover the original is unrecoverable — or worse, they hash passwords with MD5 thinking that's "encrypted storage", which protects against almost nothing. If you need to get the data back, you need encryption, not hashing.

It is not randomness. Digests look random, and they make fine deterministic identifiers, but a hash function is not a random number generator. Don't use digests as lottery draws or key material without understanding the construction — use a proper CSPRNG for secrets.

It does not authenticate by itself. A bare hash proves integrity (this data matches that digest) but not authenticity (this data came from who I think). Anyone can hash anything. Authenticity needs a signature or a message authentication code (HMAC), which combine hashing with a secret key.

A practical note

When you see a digest published next to a download, actually check it — it takes seconds with the Hash Generator for text, or your operating system's built-in tools for files (certutil -hashfile on Windows, shasum -a 256 on macOS/Linux). Most people never do, which is a shame: it's one of the simplest verification steps in computing, and it catches corrupted downloads as well as tampered ones. Just remember what you're verifying — integrity against the published digest — and get that digest from somewhere you trust.

Try the Hash Generator