Why Random Name Generators Repeat Themselves: The Birthday Paradox

Generate two thousand random identities and sooner or later the generator hands you the same person twice — in our own measured run, profile 599 was the second Reginald Schaden, and by the end eight full names had appeared twice. The first reaction is that something must be broken: two thousand draws from hundreds of thousands of possible name combinations should surely never repeat. The second reaction should be to remember a classic probability result, because the repeat is not only unsurprising — it is close to mathematically guaranteed. This is the birthday paradox, and if you use a random name generator or a random address generator to build fixtures, it is quietly shaping your data.

The birthday paradox in thirty seconds

Put 23 people in a room and the probability that at least two share a birthday is just over 50% — with 70 people it is 99.9% ^{[birthday-problem]}. The result feels wrong because intuition compares each person against one date, but the mathematics compares every person against every other person: 23 people form 253 pairs, and each pair is a fresh chance to collide. Collisions scale with pairs, and pairs grow with the square of the row count. The useful engineering consequence is a rule of thumb: drawing randomly from a pool of P equally likely values, you hit a 50% chance of a repeat after only about 1.2 times the square root of P draws ^{[birthday-problem]}. For 365 birthdays that is 1.2 × 19.1 ≈ 23 people. For a pool of a million name combinations, it is not half a million draws — it is about 1,200.

Random names collide sooner than you think

Apply the square-root rule to a name generator and the intuition flips. First names are drawn from pools of at most a few thousand values — with the pool split by gender, effectively less — so repeats begin within a few dozen draws. Full names multiply first-name and surname pools into hundreds of thousands of combinations, which sounds unrepeatable until the square root shows up: expect duplicates somewhere in the low thousands of rows. And every one of these figures is optimistic compared to the real world, because real name distributions are heavily skewed rather than uniform: the 2010 US Census counted over 2.4 million Americans named Smith and another 1.9 million named Johnson ^{[census-names]}. A dataset that mirrors reality collides even faster than a uniform pool of the same size — sharing a name is normal, which is exactly why using someone's name as an identifier is a design mistake.

What we measured on our own generator

Rather than argue from theory, we generated 2,000 US profiles with this site's engine — seeds numbered 0 through 1,999 — and counted duplicates in every field. Because each identity is a pure function of its seed, rerunning those seeds reproduces this table exactly, duplicates and all; nothing below is a fluke we could not repeat.

Three details in that table deserve a closer look. First, the email row is a dodged bullet, not a guarantee: the local part is derived from the name plus a short random number, and in this run the number happened to break every tie — a rerun with a different seed set produced two identical addresses. Fields computed from other fields inherit their collisions, minus whatever randomness gets added on top. Second, the street line never repeated: the house number is drawn from a large numeric range, so the address line behaves like a serial number even though the city and ZIP repeat constantly. Third, the birthday row is the birthday paradox in its original habitat — 100 shared birthdays in 2,000 people is startling until you recall that 23 people already give you even odds of one. And if you read our companion piece on birthdays that break software, you know why the month-day row tops out at 365 possible values rather than 366: this engine deliberately never generates 29 February.

Where duplicates actually break things

• Unique constraints on import — seed 2,000 rows into a table with a unique email column and the insert fails somewhere past row 1,000, but only sometimes: a flaky failure that depends on which seeds you drew.
• Deduplication logic in demos — a CRM demo that merges 'duplicate' contacts will quietly fold two generated Reginald Schadens into one, and your row counts stop matching for no visible reason.
• Tests that assert uniqueness — a test that generates 50 users and asserts all first names differ passes for months, then fails on an unlucky seed. The test encoded the wrong assumption, not the generator.
• Load tests with per-user caps — if the harness keys sessions on generated names or emails, collisions collapse two virtual users into one and your concurrency numbers drift low.

Uniqueness and realism are different jobs

The instinct after the first collision is to want a generator that guarantees uniqueness. But a name generator that never repeated would be failing at its actual job, which is realism — the real world hands out the same name millions of times, and software that cannot cope with two customers sharing a name has a bug that unique test data would have hidden. The clean pattern is to give each concern its own field: uniqueness belongs to an identifier that is built for it, and realism belongs to the display fields. A UUID drawn from 122 random bits will not repeat before you have generated billions of rows ^[uuid-wiki] — that is the column for primary keys, while the name column stays realistic, collisions included. Our UUID generator and UUID vs GUID explainer cover that side; in this site's free API, a seeded request always reproduces the same profile, so the seed you chose works as a stable key for the row it produced.

Keeping duplicates out of the columns that need it

1. Size the run with the square root in mind. If you need N rows with no full-name repeats, check that N is comfortably below the square root of the name-pool size — and expect to fail that check once N reaches the low thousands.
2. Deduplicate after generation, on the constrained column only. Generate 10% more rows than you need, drop rows that collide on email or username, keep the natural name duplicates.
3. Make derived fields unique mechanically. Appending the row index to an email local part preserves realism to a reader while satisfying a unique constraint exactly.
4. Key rows on seeds or UUIDs, never on generated attributes. Then a name collision is a realism feature instead of a data-integrity incident.

The birthday paradox is the third entry in what has become a series on the gap between how data looks and how it behaves: names that break software covers hostile inputs, birthdays that break software covers calendar arithmetic, and this piece covers the statistics of randomness itself. If you want to reproduce our numbers or run your own, the bulk generator exports thousands of profiles as CSV or JSON — count the duplicates yourself; the math says they are in there.