Twenty-three people, and the coincidence you should expect
Twenty-three people make 253 pairs. Nobody ever computes the 253, and that is the entire reason the answer feels wrong.
Put 23 people in a room and the probability that two of them share a birthday is 50.7%. With 70 people it is 99.9%.
Nearly everyone guesses far too high a number, and the reason they do is that they ask the wrong question. The instinct is to think about yourself: what are the odds someone here shares my birthday? That is a much rarer event, and you would need about 253 people for it to pass a half.
The actual question is about any pair at all. And pairs are not scarce.
Counting pairs, not people
Twenty-three people make 23 × 22 ÷ 2 = 253 distinct pairs. Each pair has a 1-in-365 chance of matching. The number of pairs grows as the square of the number of people, so doubling the room quadruples the opportunities for a coincidence.
The exact calculation runs the other way round: the probability that no two match, which is 365/365 × 364/365 × 363/365 × … for 23 terms, coming to 0.493. One minus that is 0.507.
The general rule worth remembering
For N equally likely possibilities, you need roughly √N draws before a repeat becomes more likely than not. For birthdays, √365 ≈ 19, and the constant works out at about 1.18 × √N ≈ 22.5. Close enough to 23.
Square root, not half. That is the number people get wrong, and it is wrong in the direction of expecting coincidences to be rarer than they are.
Where it stops being a party trick
Hash collisions. A hash table with a thousand slots does not start colliding when it gets near a thousand entries. It starts colliding at around thirty. That is why hash table implementations care about collision handling from the very first insert, and why measuring load factor alone tells you little about how many probes a lookup takes. The Hash Table tool shows collisions appearing far earlier than expected.
Cryptography. This is where the square root sets the security parameter. To find two different documents with the same 64-bit hash you do not need 2⁶⁴ attempts; you need about 2³², roughly four billion, which is minutes of work. This is the birthday attack, and it is why a hash function intended to give n bits of collision resistance must produce 2n bits of output. It is the reason 128-bit hashes are considered to offer 64 bits of collision resistance and are no longer acceptable for signatures.
Reading coincidences. Any large enough dataset contains striking coincidences, and the number of them scales with the pairs, not the records. Two people in a town winning a lottery, a cluster of an illness in one street, two songs sounding similar: these become near-certainties at scale, and treating each as individually improbable is the same arithmetic error made about people and birthdays.
The correct question is never "how unlikely is this particular coincidence?" It is "how many opportunities were there for some coincidence of this kind?" Those two numbers differ by a factor that grows quadratically, which is more than enough to turn an astonishment into an expectation.
Two objections, both worth answering
"Birthdays are not uniform." They are not: there are more births in late summer in the northern hemisphere, fewer on 25 December and 29 February, and a visible dip at weekends because of scheduled deliveries. But non-uniformity always makes matches more likely, never less: clustering concentrates people onto fewer effective days. The uniform assumption is therefore conservative, and 23 is if anything a slight overestimate.
"Twins, and people who came together." Real rooms are not random samples. A room containing siblings, or a class of schoolchildren selected by age cut-off, has correlations the model does not include. The calculation is a baseline for independent draws, and where the draws are not independent it is the independence that needs defending, not the arithmetic.
The version to carry around
If there are N equally likely categories and you take k draws, the expected number of colliding pairs is about k²/2N. Set that to one and you get k ≈ √(2N) — the same square root, arrived at by counting expected collisions rather than probabilities, and easier to do in your head.
For a thousand hash slots: √2000 ≈ 45, so expect your first collision somewhere in the forties. For a 32-bit checksum: 2¹⁶ = 65,536 items, which a log file reaches in an afternoon. For 365 days: 27, close enough to 23 that the estimate is worth trusting.
The habit is to reach for the square root whenever you hear "what are the odds of a duplicate", and to notice that the answer arrives much sooner than the size of the space suggests. The Birthday Paradox tool plots the curve, and the steepness of it around 20 to 30 people is the part that does not survive being described in words.