23 people create a 50.73% birthday-collision chance.
Precise claimIn the standard 365-day uniform model, 23 people produce 253 possible pairs and a 50.73% chance that at least two share a birthday.
Applies
The classroom model treats 365 birthdays as equally likely and ignores February 29. The page computes the exact probability and uses simulation only as a visible check.
Does not prove
Real birthdays are not perfectly uniform. A single simulation is not a proof and will fluctuate around the exact result.
Portable rule
If outcomes collide pairwise, then count pairs, not items.
Declare the discussion context, then copy a stable link. No account or personal data is attached.
How Many People Before Two Share a Birthday?
A room fills one person at a time. How many people does it take before there is a 50% chance that two of them share a birthday? Commit to a number — no hints, no warm-up.
Interactive
…The room
The year — 365 slots
The clean model: 365 days, every birthday equally likely, no February 29. Judge the number; the page shows its work.
The reveal
In the standard 365-day uniform model, 23 people produce 253 possible pairs and a 50.73% chance that at least two share a birthday.
You picked: —
23 people. With 23 people in a room, the chance that at least two of them share a birthday is 50.7% — better than a coin flip.
P(at least one shared birthday) = 1 − 365! / ((365 − n)! · 365n) n = 23 → 0.507297
You picked 23 — correct. Either you have met this paradox before, or your intuition is unusually well calibrated. The simulation below will still test whether you believe it.
You picked 57 — that is the answer to a different question: 57 people gets you to 99%, not 50%. For a coin-flip chance, 23 is enough.
You picked 183 — half of 365. That is the classic move: matching people against days. But birthdays do not collide with days; they collide with each other.
You picked 365. Even that is no guarantee — certainty needs 366 people, by the pigeonhole principle. And a 50% chance arrives far earlier: at 23.
Every new person does not add one more chance — they add one chance against everyone already in the room. Person number 23 adds 22 fresh pairs at once.
You counted people. The math counted pairs.
The rebuilt model
You assumed:
A room must contain roughly half of 365 people before a collision becomes likely.
The actual model:
Collisions grow with the number of pairs, n(n−1)/2, not with the percentage of calendar days occupied.
The variable that failed you:
Pair count — 23 people create 253 chances to collide.
One variable: how many people
1,000 classrooms of 23 people, birthdays drawn live from your browser's crypto random source. Watch the share of classrooms with a shared birthday settle near 50.7% — then drag the slider and judge once more.
Reduced motion is on, so the simulation runs in a single step instead of streaming its tally. The randomness and the math are identical.
Interactive
The simulation — 1,000 classrooms of 23
—not run yet
Tick = the theory: 50.7%. The fill is this run's live tally.
Birthdays from crypto.getRandomValues, rejection-sampled to kill modulo bias. View source — the whole simulator is on this page.
One classroom from this run (sorted day-of-year numbers)
Interactive
The curve — the formula from the reveal, computed live
23 people → 50.7% · 253 pairs
Right — 57 people. The curve crosses 99% between 56 (98.8%) and 57 (99.0%). Certainty gets cheap once pairs multiply: 57 people is 1,596 pairs.
99 people is massive overkill — the chance is 99.99996%, and the no-collision odds are about 4 in 10 million. The curve already crossed 99% back at 57.
183 is the people-vs-days reflex again. At 183 people the no-collision chance is under 1 in 10²⁴ — the curve crossed 99% at 57.
Notice what changed: this time you read pairs off a curve instead of dividing the year in half. That is the rebuilt model doing its job.
Check the formula in any browser console: p=1;for(let i=0;i<23;i++)p*=(365-i)/365;1-p — you will get 0.507297….
Rerun the simulation above. Every run draws fresh birthdays from crypto.getRandomValues; the classroom share lands near 50.7% each time.
Count the pairs by hand: 23 people → 23×22/2 = 253 pairs. Add one more person and you get 276 pairs — a single person added 23 new chances to collide.
Interactive
Playground — change the space, not the people
23 people, 365 days → 50.7%
Keep 23 people and stretch the space. This is exactly the hash-collision problem: the "days" are your ID space, the "people" are your records.
Scope: The classroom model treats 365 birthdays as equally likely and ignores February 29. The page computes the exact probability and uses simulation only as a visible check.
Does not prove: Real birthdays are not perfectly uniform. A single simulation is not a proof and will fluctuate around the exact result.
Take it with you
The portable rule
If outcomes collide pairwise, then count pairs, not items.
Identifier design
Estimate hash, code, or UUID collisions from the number of generated pairs.
Testing
Many component interactions can create far more pairwise cases than the component count suggests.
Team discussion
Ask whether the risk grows per item or per possible relationship between items.
Interactive
Apply it — five seconds
Your product issues 8-digit redemption codes (100,000,000 possible values) to 1,000,000 users. Should you worry about two users getting the same code?
Right. A million users make ~5×10¹¹ pairs against 10⁸ codes — expect roughly 5,000 colliding pairs. "1% full" measures items against the space; collisions run on pairs.
Careful — fullness is the wrong axis. 10⁶ users make ~5×10¹¹ pairs, and against 10⁸ codes that is roughly 5,000 expected collisions. Count pairs, not items.