Birthday Paradox Explorer

shared birthday probability vs group size

Worked example — Birthday Paradox Explorer

P(shared birthday)	50.7%
1. Number of people in the room (n):	23
2. Total pairs to compare (n × (n-1) / 2):	253 pairs
P(all unique)	49.3%
Pairs compared	253

These are the values the calculator shows when the page opens. Change any input above to recompute them.

Loading interactive simulation...

Lesson

The theory — Birthday Paradox Explorer

The birthday problem asks for the probability that at least two people anywhere in the group share a birthday. It is not the probability that someone matches you, and it is not about any particular date — that distinction is the whole reason the answer feels wrong.

What each symbol means

P(match): the probability that some pair shares a birthday — the headline figure, 50.7% at n = 23.
P(all unique): the probability that no two people share one. The two always add to 100%: 50.7% + 49.3%.
pairs: how many pairs the group contains, n(n−1)/2 — at 23 people that is 253, and it is pairs rather than people that drives the probability up.

How to read what you see

The two probabilities come first, then the pair count, then a numbered walk-through. Below that the formula shows exactly what was multiplied: 1 − (365/365 × 364/365 × ⋯ × 343/365), one factor per person, ending at 1 − 0.492703 = 0.507297. Each factor is the chance the next person misses every birthday already taken.

Assumes: 365 equally likely birthdays, independent between people. No leap days, no twins, and no seasonal pattern in births — all three are false in the real world, which is why this is a clean model rather than a demographic prediction.
Breaks when: The uniform assumption is not conservative in the direction you might guess. Real birth dates clump seasonally, and any departure from uniformity raises the chance of a collision — so 50.7% at 23 people is a floor, not an estimate. Push the slider to 80 and the probability rounds to 100%, but it never actually reaches it: with fewer than 366 people a no-match outcome always remains possible.

the paradox of pairs, not people 🖖

The paradox dissolves once you stop counting people and start counting pairs. With 23 people there are only 23 birthdays to compare, but C(23,2) = 253 distinct pairs that could each turn up a match — and it only takes one. Human intuition anchors on 'how many people are like me,' which grows linearly, while the quantity that actually matters, the number of pairwise comparisons, grows quadratically as n(n−1)/2. That's why the probability curve rockets upward so early: past n=23 you've already crossed 50%, and by n=57 it's over 99%, because you're feeding the problem O(n²) worth of opportunities to collide.

why we compute the opposite 🖖

Instead of tracking every way a match could appear, the tool asks the far easier reverse question: what's the chance everyone's birthday is different? Add people one at a time — the second must miss 1 taken day (364/365), the third must miss 2, and so on — then multiply those shrinking fractions and subtract from 100%. The takeaway: at 23 people the 'all different' chance finally dips below half, which is exactly why 23 is the tipping point.

the same math cracks cryptography 🖖

The identical logic quietly governs digital security. To break a hash function an attacker rarely needs a specific target — any two inputs that produce the same output will do, which is precisely the 'any pair' problem. So a hash with N possible outputs falls to a birthday attack after roughly √N attempts, not N. That's why a 256-bit hash gives only about 128 bits of collision resistance, and why designers must double the length to stay safe.

Practice

Check yourself

Predict the answer first, then use the controls above to find out. Reveal only after you have committed to a guess — that is what makes it practice.

Ten people make 45 pairs, and each pair has about a 1-in-365 chance of matching — which suggests 45/365 = 12.3%. The panel says 11.7%. Which way is the quick estimate wrong, and why is it wrong in that direction?

Show answer

It overestimates, and it always will. Adding up 45 pair-chances counts every double coincidence more than once: that sum is the first term of an inclusion–exclusion series whose next term subtracts. The panel goes the honest way round instead — P(all unique) = (365/365)(364/365)…(356/365) = 88.3%, and 100% − 88.3% = 11.7%. The gap widens fast: at 23 people the quick sum gives 253/365 = 69.3% against a true 50.7%, and once a group has more than 365 pairs the quick sum sails past 100%, which is the plainest possible proof that it was never a probability.
Push the group size to its maximum of 80. P(shared birthday) reads 99.99% — not 100%. How many people does it take before a shared birthday is genuinely certain?

Show answer

366, or 367 once you allow 29 February. That is the pigeonhole principle, and it is the only route to certainty: with 365 possible dates, 366 people cannot all be different. Everything below that is merely likely, however close it looks. The slider stops at 80 because that is where the curve does its work — it is already at 99.99% there, and the remaining 286 people buy only the last hundredth of a percent. Watch the panel add a second decimal at n = 73 rather than print a 100% it cannot justify.

Problems solved in full

23 people in a room with a shared birthday 5 steps
How many people must be in a room before a shared birthday is more likely than not? Derive it, then explain why 23 feels far too small.
1. Compute the opposite. “At least one shared” is awkward because the sharing can happen in many ways at once; “all different” is a single clean sequence of choices.
  
  $P (all different) = k = 0 \prod n - 1 \frac{365 - k}{365}$
2. Each new person must avoid all the birthdays already taken, so the available days shrink by one each time. Multiply the fractions.
  
  $n = 23 : \frac{365}{365} \cdot \frac{364}{365} \dots \frac{343}{365} = 0.4927$
3. Subtract from one. The explorer above prints exactly this, and 23 is the first n for which the result passes a half.
  
  $P (shared) = 1 - 0.4927 = 0.5073 = 50.7%$
4. You are not comparing yourself with 22 others — every pair counts, and the number of pairs grows as the square of the group.
  
  $(2 n) = \frac{23 \times 22}{2} = 253 pairs$
5. That squared growth is visible in the approximation: the probability depends on n² over 730, so the crossing point goes as a square root, not a fraction of 365.
  
  $P \approx 1 - e^{- n^{2} /730} : n = 730 ln 2 = 22.5$
Answer

23 people, for a 50.7% chance. The intuition that fails is a question-substitution: people picture "someone shares my birthday", which needs 253 people for even odds, when the question asked is "any two of us", which has 253 pairs at n = 23. The square-root scaling is the general lesson, and it is why hash collisions appear after roughly √N insertions rather than N — the same arithmetic decides how long a hash needs to be.

$n = 23 \Rightarrow P = 50.7% pairs = (2 23) = 253$
The 50.7% rule for twenty-three people in a 365-day year 6 steps
Twenty-three people, 50.7%. The number everyone remembers is 23, and it is the least useful part of the result — it belongs to a 365-day year and nothing else. Find the rule underneath it, the one that still holds when the calendar is a hash function.
1. The exact answer is a product: the second person misses the first, the third misses both, and so on down the room. That product is what the panel evaluates.
  
  $Q (n) = k = 0 \prod n - 1 \frac{365 - k}{365}, P = 1 - Q (23) = 0.507$
2. Products are hard to reason about, so take logarithms — and while k is small against 365, each logarithm is very nearly its own argument. What is left is a sum of the first n−1 integers.
  
  $ln Q = k = 0 \sum n - 1 ln (1 - \frac{k}{365}) \approx - k = 0 \sum n - 1 \frac{k}{365} = - \frac{n ( n - 1 )}{730}$
3. Set the probability to a half and solve. The n² term dominates the n, so the answer is a square root, and it lands within half a person of the 23 on the panel.
  
  $P = \frac{1}{2} ⟹ \frac{n ( n - 1 )}{730} = ln 2 ⟹ n^{2} \approx 730 ln 2 = 506.0 ⟹ n \approx 22.5$
4. Now write it with no 365 in it. The year was never special: for N equally likely slots the halfway point sits at about 1.1774√N.
  
  $n \approx 2 N ln 2 = 1.1774 N : N = 365 ⟹ 22.49$
5. Apply that where it actually bites. A 32-bit hash has 2³² slots, which sounds enormous — but the square root of an enormous number is not enormous.
  
  $N = 2^{32} : n \approx 1.1774 2^{32} = 1.1774 \times 65536 = 77162$
6. Measure that against the size of the space it is drawn from.
  
  $\frac{77 162}{2 ^{32}} = 1.8 \times 1 0^{- 5} = 0.0018%$
Answer

The threshold grows like √N, not like N/2 — and for a 32-bit hash that means 77,162 items, 0.0018% of the space, before a collision is more likely than not. That is the birthday attack, and it is why 32-bit checksums are useless for deduplicating anything at scale, and why hash outputs are sized in bits with the square root already assumed. The 23 on the panel is a single point on that curve. The curve is the part that transfers.

$n \approx 1.1774 N : 365 \to 23, 2^{32} \to 77162$

Learning path

When two things land on the same value

Leads to Hash tables the pair-counting argument and the habit of computing the complement — the chance that nothing collides.

References (1)

Why real, non-uniform birth dates make a collision MORE likely, not less — so 50.7% at 23 people is a floor: A. G. Munford, “A Note on the Uniformity Assumption in the Birthday Problem.” The American Statistician 31, 119, 1977.

By the 42Math team · Updated 2026-05-15

Reviewed against published sources. Corrections welcome. Editorial policy · Corrections

All Statistics & Finance lessons →

Example problems

office n=10 - n=10 -> 11.7% chance - feels safe, but 45 pairs are already being compared
class n=23 - n=23 -> 50.7% chance - the famous crossover: more likely than not
room n=30 - n=30 -> 70.6% chance - roughly 2-in-3 for a typical classroom
hall n=57 - n=57 -> 99.0% chance - near-certainty with just 57 people