How hash functions actually work

A hash function is a deterministic procedure that turns an input of any size into an output of fixed size. Feed in 3 bytes or 3 gigabytes — out comes the same number of bits every time. Hash the same input twice and you get the same result. Change a single bit in the input and the output looks completely different.

Not every hash function is built for security. The split matters because the design goals — and therefore the speed, output size and resistance to attack — are completely different.

MD5, SHA-1 and the SHA-2 family all share the same overall blueprint, called Merkle-Damgård construction. Understanding it once is enough to understand all four algorithms — they only differ in the details inside the box.

The padding step is what makes hash functions safe against length-extension on protocols — but only if the protocol uses the hash correctly. (MD5 and SHA-1/2 are themselves vulnerable to length-extension; HMAC and SHA-3 fix this in different ways.)

MD5 (Message Digest 5) was published by Ron Rivest in 1991. It compresses any input into a 128-bit (16-byte, 32 hex character) digest. The algorithm is still in widespread use for non-security purposes despite being cryptographically broken.

Step by step

Why it's broken

In 2004, Wang and Yu published a practical method for finding MD5 collisions — two different messages that hash to the same value — in seconds on commodity hardware. In 2008, researchers used MD5 collisions to forge a rogue Certificate Authority. Today, MD5 collisions are trivial; use it only when collisions don't matter (e.g. cache keys, file deduplication, checksum-only integrity).

→ Try the MD5 generator

SHA-1 (Secure Hash Algorithm 1) was designed by the NSA and published by NIST in 1995. It outputs a 160-bit (20-byte, 40 hex character) digest. Famously used by Git for commit IDs.

Why it's deprecated

In 2017, Google's SHAttered attack produced two distinct PDF files with the same SHA-1 hash. The attack required about 9 quintillion (9×10¹⁸) hash computations — out of reach for most attackers, but well within reach of a determined adversary. NIST deprecated SHA-1 for digital signatures in 2011. Browsers stopped trusting SHA-1 TLS certificates in 2017. Use SHA-256 or higher for anything security-relevant.

→ Try the SHA-1 generator

SHA-2 is a family of six functions published by NIST in 2001: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256. They all share the same general design but use one of two underlying engines:

Inside the compression function

Each block is split into 16 words, then expanded to 64 (SHA-256) or 80 (SHA-512) words using a non-linear schedule of rotations, XORs and shifts. The compression loop maintains 8 state words (a–h). At each round:

Σ₀, Σ₁, Ch (choose) and Maj (majority) are simple bit-level mixing functions. K[t] is a round constant derived from the cube roots of prime numbers. W[t] is the expanded message word. The whole thing is fast on modern CPUs — and on hardware with SHA extensions (Intel SHA-NI, ARM Crypto), it's extremely fast.

Security status

SHA-256 and SHA-512 have no known practical attacks in 2026, more than two decades after publication. The best-known collision attack on SHA-256 still requires roughly 2¹²⁸ operations — entirely infeasible. These are the algorithms you should pick by default.

CRC-32 (Cyclic Redundancy Check, 32-bit) is not a cryptographic hash at all — it's an error-detection code. It's designed to catch accidental bit-flips during transmission or storage, not to resist deliberate tampering.

The math: polynomial division

CRC-32 treats the input as a long binary number and divides it by a fixed 33-bit "generator polynomial" — for the most common variant (used in ZIP, PNG and Ethernet), that's 0xEDB88320 reversed. The remainder of that division is the CRC.

CRC-32 detects all single-bit errors, all double-bit errors, all odd numbers of errors, and any burst error shorter than 32 bits. It is trivial to forge a collision — you can construct any message with any target CRC in O(n) time — so never use it for security purposes.

→ Try the CRC-32 generator

Adler-32 was designed by Mark Adler (of zlib fame) as a faster, simpler alternative to CRC-32 for error detection in the Deflate compression algorithm.

Adler-32 is faster than CRC-32 in software (just two additions and two modular reductions per byte) but has weaker error-detection properties: it fails to catch certain swap-style corruptions and is sensitive to leading zero bytes. It's still good enough for zlib's purpose, where the underlying stream is already compressed and therefore "random-looking".

→ Try the Adler-32 generator

FNV-1a (Fowler-Noll-Vo, variant 1a) is a tiny, fast, non-cryptographic hash designed for use inside hash tables and bloom filters. The 32-bit variant fits in three CPU instructions per byte.

The "1a" variant XORs before multiplying (FNV-1 does it the other way around); 1a has slightly better distribution. FNV-1a has excellent statistical properties for general-purpose hashing — its avalanche behaviour is surprisingly good for such a simple function — and it's been a workhorse in databases, compilers (LLVM uses it), and bloom filters for two decades.

→ Try the FNV-1a generator

DJB2 is even simpler than FNV-1a. Posted by Daniel J. Bernstein to comp.lang.c in the early 1990s as a "fast hash function for strings", it's been quietly used inside thousands of C and C++ programs ever since.

Why 33? Why 5381? Bernstein never published a formal analysis — the constants were chosen empirically based on how well they distributed common English text. The function is fast, has excellent locality (one byte at a time, no table lookups), and remains a great choice for tiny in-memory hash maps even today. Like FNV-1a, it has zero collision resistance against an attacker who can choose inputs.

→ Try the DJB2 generator