Hash Collision Probability Calculator
Estimate hash collision risk with the birthday bound: given N items and a B-bit digest — useful for IDs, caches, and deduplication.
Results
Enter data and click Calculate.
The birthday paradox
A hash collision occurs when two different inputs produce the same hash value. Intuitive example: two different files sharing a CRC32 checksum — a tool may treat them as the same object even though the bytes differ.
In a group of just 23 people, there is already a better than 50% chance that two share a birthday — even though a year has 365 days. The same thing happens with hashes: the number of pairs to compare grows far faster than the number of items, so collisions appear much sooner than intuition suggests.
The approximation formula
The calculator uses the simplified birthday bound: P ≈ n² / (2 × 2^b), where n is the item count and 2^b is the number of possible hash values for a b-bit digest. The result is clamped at 100%. At n = 2^(b/2) the formula gives about 50% — a handy rule of thumb: "the halfway birthday point is the square root of the number of possible hashes."
Common hash sizes
| Algorithm | Length (bits) | Status |
|---|---|---|
| CRC32 | 32 | Integrity check, not cryptographic. |
| MD5 | 128 | Cryptographically broken — do not use for security. |
| SHA-1 | 160 | Deprecated — practical collisions demonstrated since 2017. |
| SHA-256 | 256 | Widely used standard, considered secure. |
Security implications
- Short hashes (32-64 bits) work fine for detecting transmission errors, but with millions of items collisions become practically guaranteed.
- For identifiers, file deduplication, or caching, a collision is usually a minor annoyance (safe systems compare the underlying data too).
- For digital signatures, certificates, and security integrity checks, a collision is a real threat (an attacker could substitute malicious data with the same digest) — there, only cryptographically resistant algorithms (SHA-256 and newer) are acceptable.
Limits of the approximation
The birthday formula is an upper-bound approximation — the exact probability is slightly lower, especially when n approaches 2^b. This tool computes the probability of any pair colliding, not resistance to a "preimage" attack (finding an input that produces a specific, chosen hash) — that is a different, much harder cryptographic problem.
Examples
- 10,000 items, 32-bit hash → about 1.16% collision chance.
- 65,536 items, 32-bit hash → exactly 50% collision chance (the birthday point).
- 1,000,000 items, 64-bit hash → about 2.7 × 10⁻⁸ — essentially zero risk.
FAQ — hash collisions
- What is a hash collision?
- It is when two different inputs produce an identical hash digest. Every hash function has this as an unavoidable consequence of having a finite number of possible outputs.
- Why does a 32-bit hash have such a high collision risk with just thousands of items?
- Because the number of pairs to compare grows at a rate of n², not n — that is exactly the birthday paradox effect. With 4 billion possible values (2^32), a collision becomes likely at around 65,000 items.
- How is a collision different from a "preimage" attack?
- A collision is finding any pair of inputs with the same hash. A preimage attack is finding an input that produces a specific, chosen hash — a much harder problem that this calculator does not compute.
- What hash size is safe for my use case?
- For deduplication and caching, 64 bits is usually enough. For cryptographic security (signatures, certificates, passwords), use SHA-256 (256 bits) or higher — never MD5/SHA-1.
- What does log₁₀(P) show?
- The base-10 logarithm of the probability — useful when P is extremely small (e.g. 10⁻²⁰), since comparing orders of magnitude is easier than comparing raw fractions.
- Is the result exact?
- It is a birthday-bound upper-approximation — very close to the exact value for typical ranges, but not mathematically identical.
- Why are MD5 and SHA-1 considered unsafe?
- Not because they are "short" in the sense this calculator measures, but because methods were found to generate collisions much faster than the birthday bound predicts — weaknesses in the algorithm itself, not just the digest length.
- Can I use this to estimate UUID collision risk?
- Yes — UUID v4 has effectively 122 bits of randomness; enter b=122 and your estimated number of generated UUIDs to get an approximate collision probability.