Two numbers go in: a digest length in bits, and a population size. Everything after that is arithmetic, and it runs in your browser. There is no request to make: the calculation needs no data beyond the two figures you type. No file to upload, no hash to submit, no account. Type 32 and 77000, and the page hands back a probability.

That number is the birthday bound: the chance that at least two of your n items share a digest. It is also the number most people get wrong: the formula in most heads, n over N, understates the real risk by a factor of 27,808 at 32 bits and 77,000 items. Your inputs never leave your device.

Key Takeaways

• Collision risk scales with n²/2N, not n/N. At 32 bits and 77,000 items the naive answer is 27,808× too low.
• The 50% point: 77,164 items at 32 bits, 2.172 × 10¹⁹ at 128, 4.007 × 10³⁸ for SHA-256.
• The bound is a floor, not a guarantee. It assumes uniform output and independent draws.
• Preimage, second-preimage and collision resistance cost roughly 2^l, 2^l and 2^(l/2).
• No calculator can rate a hash function. This one does arithmetic on two integers.

The two numbers everyone gets wrong

Most quick estimates compare one new item against the whole output space: n/N. At 77,000 items in a 32-bit space that is 1.79 × 10⁻⁵, which reads like a rounding error. It is not a rounding error. It is the wrong question.

The collision you actually care about is between your own items: "do any two of my n items collide with each other". That is a pairwise question: the number of pairs grows as n², and each pair's chance of matching stays constant at 1/N.

Estimate	Formula	32-bit digest, n = 77,000
Naive	n / N	1.79 × 10⁻⁵
Birthday bound	1 − exp(−n² / 2N)	0.49854 — 49.85%

The true value is 27,808 times the naive one.

A 32-bit digest reaches a one-in-a-million collision chance after 94 items. The textbook birthday problem (365 possible days, 23 people) comes out at 0.5073 under the same formula.

How the birthday bound is derived

1. Count the draws. A hash with an l-bit output has N = 2^l possible values. Draw n of them, each uniform and each independent of the last. Both halves are idealisations.

2. Count the misses. The probability that all n values come out distinct is the count of ordered injective tuples over all tuples:

   P(no collision) = N(N-1)…(N-n+1) / N^n = ∏(1 - i/N)
   

3. Take logarithms and keep the first order. Expand ln(1 − x) ≈ −x, sum it, and discard every term of order (n/N)²:

   ln P(no collision) ≈ -Σ i/N = -n(n-1)/(2N)
   

   Exponentiate and the exact product collapses into the birthday bound:

   P(n;N) ≈ 1 - exp(-n(n-1)/(2N)) ≈ 1 - exp(-n² / 2N)
   

4. Invert it for a threshold. Solve for n and you get n(0.5;N) ≈ 1.1774·√N. Multiply by a digest length and you have the population that puts you at a coin flip.

Wikipedia's birthday attack article gives the same approximation and the same constant, and is explicit about the assumption underneath: outputs must land in H values "with equal probability".

Why a naive implementation reports 0%

Two floating-point traps turn a correct formula into a wrong answer. For small n, n²/2N underflows toward zero, exp() returns exactly 1.0, and 1 - 1.0 is exactly 0.0: a reported 0% collision chance for a case that is genuinely 1 in 10⁹. The inverse direction has the same disease: "The subexpression ln(1/(1-p)) in the equation for n(p;H) is not computed accurately for small p when directly translated into common programming languages as log(1/(1-p)) due to loss of significance."

const p = -Math.expm1(-(n * (n - 1)) / (2 * N));       // not 1 - Math.exp(...)
const k = Math.sqrt(2 * N * -Math.log1p(-target));     // not Math.log(1/(1-p))

Two more constraints follow. Math.pow(2, 256) is Infinity, so anything past 53 bits must be worked in log space, and 1.1774·√N under-estimates the true threshold.

The 50% threshold by digest length

These are the numbers worth memorising. They come from n(0.5;N) ≈ 1.1774·√N, cross-checked to two significant figures against Wikipedia's independent table; the 160-bit and 224-bit rows are absent from that table and were computed here.

Digest	Bits	N at 50% collision	N at 1-in-10⁶ risk
32-bit reference	32	77,164	94
64-bit reference	64	5.057 × 10⁹	6.07 × 10⁶
MD5 / UUID v4 / truncated SHA-256	128	2.172 × 10¹⁹	2.61 × 10¹⁶
SHA-1 (git object ID)	160	1.423 × 10²⁴	1.71 × 10²¹
SHA-224	224	6.113 × 10³³	7.34 × 10³⁰
SHA-256	256	4.007 × 10³⁸	4.81 × 10³⁵
SHA-384	384	7.391 × 10⁵⁷	8.88 × 10⁵⁴
SHA-512	512	1.363 × 10⁷⁷	1.64 × 10⁷⁴

Read the third column against your actual row count, not against your algorithm. The bits column is what gets quoted in a design review ("we use SHA-256"), and on its own carries no information.

A 128-bit hash is not negligible — it is negligible up to a number

"128 bits is negligible" is not a fact about a hash function. It is a statement about how many objects you have, and the number is finite and far smaller than intuition suggests. At 128 bits, 2.61 × 10¹⁶ objects buys you a one-in-a-million collision chance. Nobody has 2.61 × 10¹⁶ objects. Nobody has 2.61 × 10¹³. That is why MD5 and UUID v4 have been fine in practice: a fact about populations, not about MD5.

Collision resistance is not a constant

Reviews file collision resistance as an algorithm property: strong, weak, broken. It is a function of your population, and it degrades with the square of it. The question that matters is not "is SHA-256 collision resistant?" but "how many things am I hashing?" The second carries a number. The first does not.

77,164: not a lot, until it is

The 32-bit row is the one that bites in production: 32-bit digests end up as database keys, cache bucket indexes and shard selectors, picked by people who never intended a cryptographic decision. 94 rows reaches a one-in-a-million chance. A 64-bit key buys you 6.07 million. Neither number is alarming alone; both are reachable by code nobody reviewed.

A broken collision result is not a broken hash

SHA-1 produced a practical collision in 2017, and the reflexive conclusion (SHA-1 is finished, every system using it is compromised) does not follow. A collision breaks collision resistance. It leaves preimage and second-preimage resistance untouched, which is what most signature schemes lean on.

Preimage, second preimage and collision are three different properties

RFC 4949 §4 defines all three, and the arithmetic separates them.

Property	The adversary starts with	Work factor	Birthday bound applies?
Preimage	a target digest h, and seeks s with H(s) = h	≈ 2^l	No
Second preimage	a known message s and its digest, and seeks a different s'	≈ 2^l	No
Collision	nothing, and seeks any colliding pair	≈ 2^(l/2)	Yes

The same RFC states the cost asymmetry in one sentence: to find a preimage "the amount of computation required is O(2^n)", while to "simply find any pair of values s and s' that collide, the amount of computation required is only O(2^(n/2))". NIST's glossary holds the same line, defining collision resistance as infeasibility "to find a collision" and second preimage resistance as infeasibility "to find a second preimage of a known message digest".

Nobody confuses preimage with collision; preimage resistance is the property everyone hears about constantly. The confusion that happens is between collision and second preimage, because both get filed under "SHA-1 is broken". Git's transition documentation draws the line for exactly that case: "Git requires collision and 2nd preimage resistance and does not require length extension resistance." Two properties required, one explicitly not, and the birthday bound models only the cheaper of the two.

Where the approximation stops applying

The model rests on two assumptions, and each has a failure mode.

Non-uniform output distribution

The first assumption is that all N outputs are equally likely. Where that fails, collisions arrive earlier than predicted. Wikipedia: "It is easy to see that if the outputs of the function are distributed unevenly, then a collision could be found even faster."

The practical consequence: the calculator's number is an optimistic floor on real collision risk. Non-cryptographic hashes (std::hash in C++, FNV, DJB2, Java's hashCode()) collide well above birthday prediction.

Adversarial and chosen-prefix collisions

The second assumption is that the attacker knows nothing. A birthday bound describes random draws; a real attacker picks inputs. The birthday attack article describes the chosen-prefix regime separately: "For a 50% chance of a collision, Mallory would need to generate approximately 2^((l/2)+1) hashes, which is twice the number required for a simple collision under the classical birthday problem." Structure inside the hash does better than that constant, and no population arithmetic predicts it.

This matters wherever your system accepts attacker-supplied content addressed by a digest (signed PDFs, PGP signatures, certificates).

Truncated digests

Truncating SHA-256 to 32 bits and entering 32 here gives correct arithmetic for an idealised 32-bit hash. Whether yours behaves like one depends on which bits you kept: the first bytes of a Merkle–Damgård output carry whatever bias sits there. Read the result as an upper bound.

Draws that are not independent

A per-item key or salt means your draws do not come from one shared space, so the birthday formula does not apply directly. And identical inputs collide with probability 1: if your population can hold the same file twice, your collision rate is a property of your data, not your hash.

Git, SHAttered, and the 2⁸⁰ that never came

A 160-bit SHA-1 has a birthday bound of about 1.42 × 10²⁴ items, roughly 2⁸⁰ objects, more than have ever existed. By the arithmetic on this page, SHA-1 is safe indefinitely. Then, from Git's hash function transition document: "On 23 February 2017 the SHAttered attack demonstrated a practical SHA-1 hash collision." Practical, years early, and the 2⁸⁰ never came.

Git's response was staged: "Git v2.13.0 and later subsequently moved to a hardened SHA-1 implementation by default, which isn't vulnerable to the SHAttered attack, but SHA-1 is still weak." Then: "In late 2018 the project picked SHA-256 as its successor hash."

The calculator's number was irrelevant there for the same reason it is to adversarial input generally. Git's threat was never volumetric: nobody was going to produce 2⁸⁰ objects, so the attack exploited SHA-1's internal differential structure instead. A calculator modelling only n would report "SHA-1 is fine for 10²⁴ objects", which is true and beside the point.

Short identifiers are where this bites first

The birthday bound changes behaviour in short keys, not in short algorithms.

Key space	Bits	N at 50%	N at 1-in-10⁶
32-bit hash as a database key	32	77,164	94
64-bit hash	64	5.06 × 10⁹	6.07 × 10⁶
128-bit (MD5, UUID v4)	128	2.17 × 10¹⁹	2.61 × 10¹⁶

94 rows. That is the sentence to carry out of this page: short enough to remember, small enough to catch in review.

Base62 identifiers sit in the same territory: six characters over an alphabet of 62 is a space of about 35.7 bits, and the 50% point there is roughly 9 × 10⁵ identifiers. If you mint short IDs with an encoder rather than a cryptographic hash, the arithmetic still applies; only the source of the numbers changes.

What this calculator does not tell you

Five boundaries, stated plainly.

1. It does not rate any hash function. Enter 256 and it will report a 10⁻⁵⁰ probability for MD5, which is nonsense. The tool has no knowledge of any algorithm.
2. It says nothing about preimage resistance. Preimage work runs at about 2^l and follows a different curve.
3. It says nothing about second-preimage resistance. Same curve, and the property Git names alongside collision resistance, requiring both.
4. It does not model adversarial or chosen-prefix input, where cost is set by the algorithm's structure rather than your population size.
5. It does not model non-uniform output. It assumes perfect uniformity, so read every result as a floor.

Related Tools & Further Reading

• UUID validator — the same birthday arithmetic applied to the identifier format most developers already meet. A v4 is 122 random bits in a 128-bit field.
• UUID generator — mint a population and test the prediction rather than taking it on trust.
• PKCE generator — the same "how big is the space, how many have I drawn from it" question, in the one place where the answer carries security consequences.
• Base62 encoder and decoder — short encoded identifiers, the classic truncated-output case, and the 35.7-bit space above.
• RFC 4949 §4, "hash function" — the one-way, weakly collision-free and strongly collision-free definitions, with the O(2^n) versus O(2^(n/2)) costs.
• Git's hash function transition — the dated record of SHA-1 to SHA-256.