Introduction: why a room of 23 is already a coin flip
The birthday paradox usually arrives as a party bet, but the reason it wins so reliably says something useful about how we judge chance. Picture 23 people in a room. Ask most of them whether two share a birthday and they will say it is unlikely, because they are quietly answering a different question: does anyone here share my birthday? That version really is unlikely. The one this calculator answers is broader — could any two of the 23 match, whichever pair it turns out to be? Once you count every pair rather than every person, the odds cross fifty-fifty at just 23, which is where the surprise comes from.
Enter a group size and the calculator returns the probability that at least one shared birthday appears, along with the complement — the chance that all birthdays are distinct — plus a decimal form for further math, an odds ratio, and a short cue about where you sit relative to the fifty-percent mark. The same collision logic drives more than party tricks: hash tables, random tokens, coupon codes, and duplicate detection all behave like birthday problems whenever many samples fall into a limited set of slots.
How to use the birthday paradox calculator
Type the number of people into the box and press Calculate; the probabilities update at once, and Download Results (CSV) saves a small report you can drop into a spreadsheet. If you are comparing scenarios — a class of 25 against a wedding table of 40, say — change only the group size and leave everything else fixed, so what you see is the effect of headcount rather than a change in the model. The probability curve under the results plots every group size from 1 to 80 with a marker on yours, so you can see at a glance how close your group sits to the 50% crossover and how steeply the curve is climbing there.
Assumptions and limitations of the 365-day model
Every figure here rests on the textbook setup: 365 equally likely birthdays with February 29 dropped, and each person's birthday treated as independent of everyone else's. In other words, no day is favored over another and no two people are linked. The calculator accepts group sizes up to 366 so you can watch the probability reach certainty — with more people than available days, a match is guaranteed by the pigeonhole principle.
Real populations bend those assumptions a little. September births run slightly high, some weekdays see more scheduled deliveries than weekends, and twins or siblings introduce mild dependence. Those effects nudge the true probability by a fraction of a percent — enough to matter for a demographer, not enough to spoil the model for teaching, quick estimates, or intuition. If you ever need a realistic figure for a specific population, swap the uniform 1/365 for the actual daily birth frequencies and the reasoning still holds.
The formula: multiplying the matches away
The direct count of shared-birthday cases is messy, so the standard trick flips the problem: work out the chance that everyone is different, then subtract from 1. For a group of n people (with n at most 365 in the uniform model), the probability that all birthdays are distinct is a running product:
Then the probability of at least one shared birthday is:
Read the product left to right and it tells its own story. The first guest can be born any day, so the term is 365/365. The second has to dodge that one day, giving 364/365. The third dodges two, at 363/365, and so on, each new person facing one fewer free day than the last. Multiply the whole chain and you have the chance nobody collides; one minus that is your answer.
Worked example: 23 people and the 50.7% result
Take the default of 23 people. The product of 365/365 × 364/365 × … × 343/365 works out to about 0.493, so P(match) ≈ 0.507, or 50.7% — a hair past even money. That does not mean half the room shares birthdays or that duplicates pile up; it means a single matching pair exists just slightly more often than not. Two sanity checks confirm the edges: 1 person returns 0% because there is nobody to pair with, and 366 people returns 100% because you have run out of distinct days.
The benchmark table below is worth keeping within reach — if a result lands far from its neighboring benchmark, the input is probably mistyped.
| Group size | P(shared birthday) | Reading |
|---|---|---|
| 5 | 2.7% | Very unlikely |
| 10 | 11.7% | Unlikely |
| 20 | 41.1% | Approaching even money |
| 23 | 50.7% | The classic crossover |
| 30 | 70.6% | Likely |
| 40 | 89.1% | Very likely |
| 50 | 97.0% | Near certain |
| 70 | 99.9% | Effectively certain |
Sources: the complement-product formula and the 23-person crossover are the standard treatment of the birthday problem — see Weisstein, Eric W., “Birthday Problem,” Wolfram MathWorld. Benchmark values in the table are computed from the exact product under the uniform 365-day model and match the published figures (e.g., P ≈ 0.507 at n = 23, P ≈ 0.970 at n = 50). Last reviewed July 2026.
Making sense of the six outputs
The panel restates the same probability in a few forms so you rarely have to convert anything by hand. Probability of Match is the headline figure — the chance at least one pair collides — while Probability of NO Match is its complement, the chance everyone is distinct; the two always sum to 100%. Probability (Decimal) is the match figure between 0 and 1 for dropping into a spreadsheet or a model. The Odds Ratio divides match by no-match, so 2:1 means a collision is twice as likely as a clear room and anything above 1:1 tips toward a match. The Approximate Threshold line is just a plain-language flag for whether you are short of the 50% crossover, past it, or effectively certain. Keep in mind throughout that all of this describes any pair in the group, never a match against one chosen person — that separate question grows only linearly and stays small far longer.
A handful of group sizes are worth memorizing as gut checks, all under the 365-day model: 10 people sit near 12%, 20 climb to roughly 41%, 23 tip just over 50%, 30 reach about 70%, 40 near 89%, 50 around 97%, and by 60 you are within a whisker of certainty. If your result lands far from the neighboring benchmark, the input is probably off.
Where collisions ambush more than birthdays
The engine behind the steep climb is that comparisons, not people, are what pile up. A group of n holds n(n−1)/2 distinct pairs: 10 people make 45 pairs, 23 make 253, and 50 make 1,225. Any single pair matches with only a 1-in-365 chance, but hundreds of simultaneous chances add up quickly — which is exactly why the curve outruns intuition.
Swap "birthday" for "slot" and the same arithmetic explains a lot of engineering surprises. Hash functions collide, randomly generated IDs and coupon codes repeat, and deduplication passes flag matches, all sooner than the size of the space suggests. The recipe generalizes cleanly: replace 365 with k equally likely categories and the formula is unchanged; if the categories are uneven, plug in their real probabilities and the growing-comparisons lesson still carries over. Just remember the model measures only whether at least one collision exists — not how many, and not whether a specific value is the one repeated.
Birthday paradox questions people keep asking
Why does the birthday paradox feel surprising?
It feels surprising because we often think in terms of one specific person matching someone else. The paradox is about any pair matching. With n people there are n(n−1)/2 pairs, so the number of comparisons grows quickly. That rapid growth makes the probability of at least one shared birthday rise much faster than intuition suggests.
Does this calculator assume 365 days and equally likely birthdays?
Yes. The calculation assumes 365 equally likely birthdays (no leap day) and independent birthdays. Real-world seasonality and demographic effects can change the true probability slightly.
What group size gives about a 50% chance of a shared birthday?
Under the standard 365-day assumption, 23 people gives a little over a 50% chance of at least one shared birthday.
Is this the same as the chance that someone shares my birthday?
No. This calculator answers the probability that any two people in the group share a birthday. The probability that someone shares one specific person’s birthday is much smaller and grows roughly linearly with group size.
Optional mini-game: The Collision Desk
The birthday problem only becomes intuitive once betting money on it goes badly. In this optional mini-game you run a wagering desk for fourteen collision contracts. Each contract names a namespace of d equally likely slots — 365 calendar days, 1,000 coupon codes, 4,096 hash buckets, 10,000 PINs, 65,536 session tokens — and a number of draws n. A rival analyst posts a price for "at least one repeat", and you decide whether that price is too low, too high, or fair.
Every contract runs in two steps. First you read the room: drag your estimate of P(at least one repeat) onto the sealed probability curve. Then you take a side — back COLLISION, back CLEAN, or PASS — and set a stake from your bankroll. The desk then draws the n values for real from a seeded generator you can see, fills the namespace slot by slot, and reveals the exact curve computed from the complement, P = 1 − d!/((d−n)!·dn). Your read is marked against the truth, the rival's price is settled, and the bankroll ledger records the swing. Most players discover the same thing the calculator above shows: the honest number is far higher than it feels, so the rivals who price by "chance of matching one specific slot" hand you money, while the rival who uses the √d rule barely leaves an edge at all.
You start with 100 chips and need 400 chips after fourteen contracts; drop below 1 chip and the desk closes early. Namespaces grow and the rivals get sharper as the session runs, so the cheap edges disappear and stake sizing starts to matter. Two sharp reads in a row unlock the √d insight, which permanently annotates the curve with the 50% crossing at n ≈ 1.177√d and the 99% point at n ≈ 3.03√d — the same shortcut engineers use for hash and GUID collision estimates.
The Collision Desk
Fourteen collision contracts, 100 chips, a 400-chip target. Read the sealed curve, price the rival's line, then take a side before the draws are made.
Keyboard: ← → adjust, Enter confirm, C collision, K clean, P pass, R restart.
The desk is closed. Press “Open the desk” to deal the first collision contract.
Controls — pointer or touch: tap the sealed curve to place your read, then tap the buttons drawn along the bottom of the board, or use the buttons underneath it. Keyboard: focus the board (click it or tab to it), then ← / → to lower or raise the read or the stake, Enter or Space to confirm and to deal the next contract, C to back COLLISION, K to back CLEAN, P to pass, and R to restart the desk.