Why Random Name Generators Repeat Themselves: The Birthday Paradox

Generate two thousand random identities and sooner or later the generator hands you the same name twice. In our measured run, profile 599 was the second Cindy Pfeffer, and by the end eight full names had appeared twice. The first reaction is that something is broken. Two thousand draws from hundreds of thousands of name combinations should never repeat. But a classic probability result says the repeat is close to guaranteed. This is the birthday paradox. If you use a random name generator or a random address generator for fixtures, it is quietly shaping your data.

The birthday paradox in thirty seconds

Put 23 people in a room, and the chance that two share a birthday is just over 50%. With 70 people it is 99.9% ^{[birthday-problem]}. This feels wrong because intuition compares each person with one date. The math compares every person with every other person. 23 people form 253 pairs, and each pair is a fresh chance to match.

Repeats scale with pairs, and pairs grow with the square of the row count. That gives a useful rule of thumb. Drawing at random from P equally likely values, you reach a 50% chance of a repeat after about 1.2 times the square root of P ^{[birthday-problem]}. For 365 birthdays that is 1.2 × 19.1, or about 23 people. For 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 intuition flips. First names come from pools of at most a few thousand values. A fake female name generator samples only half of that. So repeats begin within a few dozen draws. Full names multiply first names by surnames into hundreds of thousands of combinations. That sounds unrepeatable until you take the square root: expect duplicates in the low thousands of rows.

Real names repeat even sooner, because real name frequencies are heavily skewed. The 2010 US Census counted over 2.4 million Americans named Smith and 1.9 million named Johnson ^{[census-names]}. Data that mirrors reality collides faster than a uniform pool of the same size. Sharing a name is normal, which is why using a 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, using seeds 0 to 1,999, and counted duplicates in every field. Each identity is a pure function of its seed. So rerunning those seeds reproduces this table exactly, duplicates and all. We last reran it on 1 October 2026.

Three rows deserve a closer look. First, the email row. The address is built from the name plus a short random number, and that number breaks most ties but not all. Our main run had one repeated address. A second run of 2,000 profiles, seeds run2-0 to run2-1999, had none, and still had seven repeated full names. Fields built from other fields inherit their repeats, minus whatever randomness is added on top.

Second, the street line never repeated. The house number comes from a large range, so the street line behaves like a serial number even though the city and ZIP repeat constantly. Third, the birthday row is the birthday paradox at home. 100 shared birthdays among 2,000 people is startling until you recall that 23 people already give even odds of one. The month-day row tops out at 365 values, not 366, because this engine never generates 29 February. Our piece on birthdays that break software explains why.

Where duplicates actually break things

• Unique constraints on import. Load 2,000 rows into a table with a unique email column, and the insert can fail partway through. It fails only for some seeds, which makes it a flaky test.
• Deduplication in demos. A CRM demo that merges duplicate contacts will fold two generated Reginald Schadens into one. 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 limits. If the harness keys sessions on generated names or emails, a repeat collapses two virtual users into one, and your concurrency numbers drift low.

Uniqueness and realism are different jobs

After the first repeat, the instinct is to want a generator that guarantees uniqueness. But a name generator that never repeated would fail at its real job, which is realism. The real world hands out the same name millions of times. Software that cannot cope with two customers sharing a name has a bug that unique test data would hide.

The clean pattern is to give each concern its own field. Uniqueness belongs to an identifier built for it, and realism belongs to the display fields. A UUID drawn from 122 secure random bits will not repeat before billions of rows ^[uuid-wiki], so that is the column for primary keys. Generate it with your platform's secure function, such as crypto.randomUUID(). The name column stays realistic, repeats included. Our UUID vs GUID explainer covers that side, and our UUID generator makes well-formed values for fixtures. In this site's free API, a seeded request always returns the same profile, so the seed works as a stable key for its row.

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 repeated full names, check that N is well below the square root of the name pool. Expect that check to fail once N reaches the low thousands.
2. Deduplicate after generating, on the constrained column only. Generate 10% more rows than you need, drop rows that repeat an email or username, and keep the natural name repeats.
3. Make derived fields unique mechanically. Adding the row number to an email address still looks realistic and satisfies 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 name pool is smaller than intuition says, and that is measurable. The Census Bureau's 2010 surname file, the frequency table most generators trace back to, records about 2.4 million people named Smith ^{[census-surnames]}. A generator that samples surnames by real frequency draws its most common names constantly. Seeding does not change the math, only the reproducibility. A seeded run, in Faker or in our engine, repeats the same collisions every time ^[faker-seed]. That is what you want when a duplicate exposes a bug and you need to see it again.

This post is part of 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 math, and this piece covers the statistics of randomness. To run your own count, the bulk generator exports thousands of US profiles as CSV or JSON. Count the duplicates yourself. The math says they are in there.