Cryptographic Hashing Explained: MD5, SHA-1, SHA-256, SHA-512

A cryptographic hash is a function that turns arbitrary input into a fixed-size fingerprint. The word “cryptographic” is doing real work in that sentence: not every hash function qualifies, and using a non-cryptographic one (or the wrong cryptographic one) is how systems quietly become insecure.

What a cryptographic hash is

Formally, a hash function H takes an arbitrary byte string and returns a fixed-length output called the digest. SHA-256 returns 256 bits, SHA-512 returns 512, MD5 returns 128. The same input always produces the same output; the same output reveals nothing about the input.

Anyone can verify a hash; only a copy of the original input can produce one. That asymmetry is what makes hashes useful for integrity checks, deduplication, content addressing, digital signatures, and (with caveats we’ll get to) password storage.

The three properties that matter

A function counts as cryptographically secure when it provides all three of these in practice:

1. Preimage resistance

Given a digest d, it should be computationally infeasible to find any input m such that H(m) = d. This is what makes hashes a one-way function — you can’t reverse the digest back to the message. For a 256-bit hash, the brute-force cost is roughly 2^256 operations, which is astronomical.

2. Second-preimage resistance

Given a specific input m1, it should be infeasible to find a different input m2 such that H(m1) = H(m2). This is the property that protects integrity: an attacker who can replace your file but can’t change its published hash needs to forge a second preimage of your exact input, which is much harder than a generic collision.

3. Collision resistance

It should be infeasible to find any two distinct inputs m1 != m2 with H(m1) = H(m2). By the birthday paradox, finding a generic collision in an N-bit hash costs about 2^(N/2) operations, not 2^N. That’s why SHA-1’s 160-bit output is no longer enough — 2^80 is well within reach of a determined adversary in 2026.

The avalanche effect

A non-formal but practical property: a one-bit change to the input should produce a wildly different digest, with about half the output bits flipped. This is what makes hashes useful for diffing — you can’t tell whether two inputs were “almost the same” from their digests, which is the whole point.

The deprecated ones — and why

MD5 (1992)

128-bit output. Collisions were first published in 2004 by Xiaoyun Wang; by 2008 researchers used MD5 collisions to forge a rogue Certificate Authority. Today you can find an MD5 collision on a laptop in minutes. MD5 is dead for any security purpose — signatures, certificates, deduplication where adversarial input is possible, anything that needs collision resistance.

MD5 is still acceptable as a non-cryptographic checksum for accidental corruption — a CD-ROM ISO download, an internal cache key — but never label it “secure” in a spec sheet.

SHA-1 (1995)

160-bit output. The 2017 SHAttered attack from Google and CWI produced two distinct PDFs with the same SHA-1 hash at a cost of around 2^63operations — expensive but feasible. NIST formally deprecated SHA-1 for digital signatures in 2011 and disallowed it for federal use in 2030. All major browsers stopped trusting SHA-1 TLS certificates by 2017.

Git is the prominent holdout, with mitigations (SHAttered detection) compensating for the underlying weakness. New protocols should not use SHA-1.

The SHA-2 family

SHA-2 is a family of hashes designed by NSA and published by NIST in 2001: SHA-224, SHA-256, SHA-384, SHA-512, plus the truncated variants SHA-512/224 and SHA-512/256. The number is the output length in bits.

Despite sharing a name, SHA-2 is structurally unrelated to SHA-1; the attacks that broke SHA-1 don’t carry over. After twenty-five years of cryptanalysis, SHA-256 remains unbroken — the best known attacks affect only round-reduced toy versions.

• SHA-256 is the practical default in 2026. 256-bit digests, 128-bit collision security, hardware acceleration on every modern CPU.
• SHA-512 is faster on 64-bit machines and produces a longer digest. Use it when you want a margin larger than 128 bits of collision security.
• SHA-224 and SHA-384 are SHA-256 and SHA-512 with the output truncated. They exist for legacy compatibility (key-length matching with elliptic curves); new designs should default to the un-truncated forms.

You can verify any of these in seconds against our in-browser hash generator — it runs locally with the Web Crypto API, so nothing leaves the device.

SHA-3 and when it matters

NIST ran an open competition from 2007 to 2012 to select a structural backup for SHA-2. The winner was Keccak, standardised as SHA-3 in 2015. SHA-3 uses a fundamentally different construction (the spongefunction) so a hypothetical break of SHA-2’s Merkle-Damgård structure wouldn’t break SHA-3.

SHA-3 is generally slower than SHA-2 in software but comparable or faster in hardware. It’s the right choice when you specifically want algorithmic diversity (e.g. signing the same data with both SHA-2 and SHA-3 for defence in depth), or when you’re on a platform with dedicated SHA-3 hardware. For everything else, SHA-256 remains the practical default.

Why you don’t hash passwords with SHA-256

This is the most common mistake in this whole subject. SHA-256 is fast — a modern GPU can compute billions per second. For an attacker who has stolen your password database, that speed is exactly the wrong property: every guess they want to check costs nanoseconds.

Password hashing functions are designed to be deliberately slow and memory-hard, so that scaling an attack with custom hardware (ASICs, FPGAs) gets expensive instead of free. The three names worth knowing in 2026:

• bcrypt (1999). Tunable work factor (cost parameter). Still secure; the limit is its 72-byte input cap. Default choice when integrating with existing libraries.
• scrypt (2009). Memory-hard, harder to accelerate with ASICs than bcrypt. Used by Litecoin and a handful of password databases.
• Argon2(2015 PHC winner). The current recommendation. Argon2id is the variant to use — it’s resistant to both side-channel and GPU attacks. Specified in RFC 9106.

All three accept a salt (a per-user random value appended to the password before hashing). The salt eliminates rainbow-table attacks and ensures two users with the same password get different stored hashes. Modern libraries handle salt generation for you; do not skip it.

HMAC: hashing with a key

A hash answers “is this data unchanged?”. An HMAC answers “is this data unchanged anddid someone who knows the shared secret produce this MAC?”.

HMAC is built on top of any cryptographic hash — HMAC-SHA-256 is the common one — via a specific construction defined in RFC 2104. The naive alternative, H(key || message), is vulnerable to length-extension attackson Merkle-Damgård hashes (which includes SHA-256). HMAC’s nested construction prevents this. Always use HMAC, not the naive form.

HMAC is the workhorse of API signing (AWS SigV4, webhook signatures, JWT’s HS256), TLS record-layer authentication, and any protocol that needs “this came from someone with the key” assurance. The same primitive shows up in the broader auth ecosystem — session cookies, OAuth bearer tokens, and CSRF double-submit tokens all lean on HMAC or a hash to bind a value to a secret the server holds.

Real use cases

Integrity checking

Publish the SHA-256 of a download alongside the file. Anyone can hash their copy and compare. This is how every Linux distribution distributes ISOs and how package managers verify dependencies. The hash itself must be delivered over a trusted channel (HTTPS to the project site, signed by the project’s signing key) — an attacker who can modify the file can usually also modify the hash if they’re on the same channel.

Content addressing

Git, IPFS, Docker layers, and many other systems address objects by their hash. The hash is the name. This gives free deduplication (identical content has identical hashes) and free integrity (if the hash matches, the bytes match).

Digital signatures

Signing a multi-megabyte file directly with an RSA or ECDSA key would be slow. The standard pattern is to hash the file and sign the hash. The security of the signature inherits the collision resistance of the hash — which is why SHA-1 signatures are no longer trusted by browsers.

Blockchain proof-of-work

Bitcoin’s proof-of-work asks miners to find an input whose SHA-256 (twice, actually) starts with a certain number of zero bits. There’s no shortcut, so the only way to find such an input is to try a lot of candidates — which is the “work” in proof-of-work. Ethereum moved off proof-of-work in 2022 to proof-of-stake, but the underlying hash-based primitive is still ubiquitous in cryptocurrency.

Deduplication

Dropbox, Backblaze, and every modern object store deduplicate at the block level by hashing each block and keeping one copy per unique hash. SHA-256 is overkill for non-adversarial dedup; many systems use a faster non-cryptographic hash (BLAKE3, xxHash) and accept the astronomically small collision probability.

Quick reference

The honest takeaway

For general-purpose hashing in 2026, use SHA-256. For passwords, use Argon2id. For authentication tokens, use HMAC-SHA-256 (or a proper JWT library that uses one under the hood). For integrity of downloads, publish SHA-256 digests over HTTPS.

The wrong answers — MD5 anywhere security matters, SHA-1 for new signatures, SHA-256 for passwords — are the most common mistakes in the breach reports. Picking right is mostly about knowing which question each algorithm is designed to answer.