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?
Add people one at a time. When does a shared birthday feel more likely than not? Stop the room when your judgment changes, then lock it.
Interactive
2 people·1 possible pair
Each new person connects to everyone already in the room.
The clean model uses 365 equally likely birthdays and excludes February 29. The probability stays hidden until you commit.
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 locked: —
23 people gives a 50.7% chance that at least two people share a birthday — better than a coin flip.
P(at least one shared birthday) = 1 − 365! / ((365 − n)! · 365n) n = 23 → 0.507297 · 253 pairs
You stopped below the 23-person threshold. The live simulation and exact curve will show how close your room came, without turning the result into a score.
You stopped at the threshold. 23 people create 253 possible pairs, enough to move the exact chance just past 50%.
You kept adding after the threshold. The extra people do not just add occupancy — each one adds a fresh connection to everyone already in the room.
Every new person adds one chance against everyone already in the room. Your locked room contains 253 possible pairs; the latest person added 22 fresh connections.
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.
Evidence, then a new collision domain
First watch 1,000 classrooms test the exact model. Then apply the pair rule to a system that generates 23 short codes every day.
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
23 ÷ 365 compares items with slots, but it is not the chance that any two codes collide. The risk comes from relationships between codes.
Right model. 23 codes create 253 pairs. The exact chance of at least one collision is 50.73% under this toy 365-slot model; the pair count tells you where to start.
A simulation can illustrate the result, but it cannot replace the model. Count the 253 pairs first, then use the exact collision formula or a calibrated simulation.
Notice what changed: the objects are now short codes, not birthdays. The collision mechanism stayed the same because the pair count stayed the same.
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.
Short-code systems
Estimate code-collision risk from the number of generated pairs, not from codes divided by available slots.
Identifier design
Estimate hash 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.