Here is a bet you should take. Get twenty-three people into a room — a small seminar, a football squad, a decent dinner party — and wager that two of them share a birthday. Not your birthday; any two of them, matching each other. It feels like a mug's bet. There are 365 days and only twenty-three people; surely the odds are slim. In fact you'll win this bet more often than you lose it, and the reason you doubt it is the same reason the maths matters far beyond parties.
The trap is a quiet swap. You picture yourself standing in the room, scanning for someone who matches you — and for that, twenty-three is indeed hopeless; you'd need over 250 people for even odds. But the bet was never about you. It's about any pair. And pairs, as we'll see, are far more plentiful than people.
01 Fill the room, one guest at a time
Start with an empty room and let people file in. Each new arrival brings a fresh chance to match someone already there. Drag the slider and watch the probability that some two guests share a birthday.
The curve climbs shockingly fast. Twenty-three people give you just over even odds; fifty push it to ninety-seven per cent; seventy and you're at 99.9%. Long before the room is anywhere near full, a shared birthday goes from "unlikely" to "practically guaranteed".
02 Why it feels wrong: count pairs, not people
Your intuition tracks the wrong quantity. It counts people — twenty-three of them against 365 days — and concludes the room is nearly empty. But a match doesn't happen to a person; it happens to a pair. And the number of pairs grows much faster than the number of guests. Add the twenty-third person and you don't add one chance to match, you add twenty-two of them, one against each guest already seated.
Do the sum and twenty-three people make 253 distinct pairs — already more than half the 365 days in a year. That quadratic explosion is the whole secret: double the guests and you roughly quadruple the pairs. The room fills with opportunities far faster than it fills with people, and every one of those 253 pairs is quietly rolling the dice.
03 The maths, and the shortcut
The exact calculation runs through the "no match" side, because that's the easy one. The second person must dodge the first (364 days out of 365 are safe), the third must dodge both, and so on:
P(match) = 1 − ( 364/365 × 363/365 × 362/365 × … )
There's a cleaner way to see it, though. With k people there are k(k−1)/2 pairs, and each pair matches with probability 1/365. Multiply those out and the chance of no match is close to e−pairs/365. At twenty-three people that exponent is 253/365 ≈ 0.69, and e−0.69 ≈ 0.50. Half. There's your fifty-fifty.
Written that way, one thing jumps out: 365 was never special. Replace it with N, the number of possible values — days, lockers, hash outputs, anything — and the chance of a collision is about 1 − e−k²/2N. Even odds arrive when k reaches roughly 1.2 × √N. The square root is the punchline. To get a collision you don't need anywhere near N draws; you need about the square root of N. For birthdays that's √365 ≈ 19, nudged up to 23. For everything else, it's a warning.
04 The same trick, in a much bigger room
A birthday is just a random draw from 365 boxes. Nothing about the argument cared that the boxes were days. So point it at something a programmer actually ships: random identifiers. Below is the very same curve, but now you choose how many boxes there are — from a year of birthdays, to a single byte, to the full space of a version-4 UUID. Watch how far you must drag before a collision becomes likely.
The threshold moves, but slowly. A byte collides within a handful of draws; 32 bits — the width people reach for when they want "surely enough" — hits even odds at only about 77,000 draws, which is why 32-bit identifiers collide in real systems all the time. A full UUID, with its 122 random bits, holds out until roughly 2.7 quintillion draws. That gulf between "sounds huge" and "actually safe" is exactly the square root at work.
05 So should you lose sleep over UUIDs?
Almost certainly not — and now you can say why with numbers rather than faith. A version-4 UUID hands you 122 random bits, and the square-root rule sets the danger line not at "all of them" but at its square root. Here's the ledger:
- Random bits in a UUIDv4122
- Distinct possible values2¹²² ≈ 5.3 × 10³⁶
- UUIDs for even odds of one collision≈ 2.7 quintillion
- …generating a billion every second≈ 86 years
- UUIDs for a one-in-a-billion risk≈ 100 trillion
Put plainly: you could mint a billion UUIDs every second for a human lifetime and still be at coin-flip odds of a single clash. Generate a hundred trillion of them and your chance of any collision is about one in a billion. For any normal application the honest answer is that a UUID collision will never happen to you — not because collisions are impossible, but because the square root of 2¹²² is still an astronomically large number. The birthday problem giveth surprises to small rooms and taketh them away from large ones.
06 So what?
The lesson is a habit of mind: when you want to know how likely a coincidence is, count the pairs, not the things. It's why a room of twenty-three feels empty but isn't, why "random enough" 32-bit IDs quietly collide, and why 122 bits of randomness is genuinely, provably plenty. Any time something is drawn at random from a fixed set of possibilities, trouble starts not at N but at √N — sooner than intuition for the small room, and far, far later for the large one.
Coincidences live in the pairs, not the people. Count them properly and the impossible party trick and the safe database ID turn out to be the very same sum.