How the name generator samples

The name generator on the homepage does one thing: it takes a real list of names from the U.S. Social Security Administration's baby-names dataset, removes every row that fails your filters, and draws from what is left with your browser's cryptographic random number generator. It never invents a name, never orders results by preference, and never fills a gap. This guide walks through each step with the actual 2025 data and with worked draws run through the same sampling code the page uses, fed a known sequence of bytes so every result can be checked by hand.

Every figure below is computed at build time from the committed SSA files, the same files the generator reads in the browser. The methodology page states the conventions; this page shows the mechanics.

Step 1: the pool is one SSA list

A spin starts by choosing a list. The era control offers 8 options: the 2025 data, which carries the top 1,000 names per sex, and 7 decade snapshots from 1955 to 2015, each a single SSA year committed to rank 200. The gender control then picks the girls' list, the boys' list, or both; "both" concatenates the two lists, so a 2025 spin over girls and boys begins with 2,000 rows, each a (name, rank, count) line from the SSA file, with the sexes kept separate even when a spelling is shared.

The depth is a hard edge. A decade snapshot stops at rank 200 and the 2025 list at rank 1,000; nothing below either exists in the committed files, so no filter can reach it and no spin can show it. A name ranked deeper is outside the committed depth, not absent from the SSA's records; decade snapshots explained covers why each era is a single year and how deep each list goes.

Step 2: the filters subtract, never add

Three filters then act on the pool. Each only removes rows; a name must pass all three to stay in.

• Starting letter keeps names whose SSA spelling begins with the chosen letter. In the 2025 girls' top 1,000, the initial with the most names is A, with 170 — 16.7% of the births in that list, which ranks it #1 of the 26 initials by share. That pool is used for the draw in step 3.
• Length is counted on the SSA spelling: short is 4 letters or fewer, medium is 5–7, long is 8 or more (the distributions behind each class are in short, medium, and long names). Over the 2025 girls' top 1,000 that gives 146 short names (the first in rank order is Emma, #3), 723 medium names (the first in rank order is Olivia, #1), 131 long names (the first in rank order is Charlotte, #2).
• Popularity tier is a rank range inside the selected era's own list, so the same tier means different names in different years:

The 1955 column shows the depth rule at work. The less common tier spans ranks 101–500, but the snapshot ends at rank 200, so only 100 of its rows exist there. The uncommon tier begins at rank 501, past the depth entirely, and holds 0 rows in every decade era — a structural gap the generator reports rather than fills.

Because the filters intersect, combinations shrink quickly. In the 2025 girls' list, the letter A alone keeps 170 names; adding medium length and the top-100 tier leaves 11 names — Amelia (#4), Ailany (#14), Aurora (#15), Avery (#37), Abigail (#41), Adeline (#59), Alice (#65), Addison (#84), Audrey (#86), Autumn (#88), Amara (#98).

Step 3: one draw by rejection sampling

With the pool fixed, the generator needs one index chosen uniformly from it. It reads bytes from crypto.getRandomValues and maps them onto the pool by rejection sampling, not by scaling or a modulo. Take the pool of 170 A girl names from 2025. Its largest index is 169, which needs 8 bits, so the sampler reads 1 byte per attempt and uses every bit; the mask is 255 (binary 11111111), which discards nothing. A candidate can be anything from 0 to 255, but the pool only has indices 0 to 169, so any candidate of 170 or above is rejected and fresh bytes are read. That accepts 66.4% of attempts here; because the bit count is the smallest that covers the span, acceptance is always above 50% and the expected number of attempts stays below 2.

Why reject rather than wrap with a modulo? With 256 candidate values and 170 names, a modulo would map 86 names onto two values each and the rest onto one, so those 86 would be drawn twice as often. Rejection discards the surplus values instead of folding them onto the low indices.

Here is the real uniformInt run on that pool with a scripted byte source in place of the browser's, handing over the bytes 255, 85 in that order:

1. First attempt: the raw byte reads 255, a candidate of 255, which is not below 170, so it is rejected.
2. Second attempt: the byte 85 reads as 85, which is below 170, so it is accepted.
3. Result: index 85 of the pool, which is Alivia — rank #484 among 2025 girls with 619 registered births. The sampler consumed 2 bytes in total.

Step 4: several names, no repeats

Repeating step 3 and discarding duplicates would waste draws and make the number of reads unpredictable. Instead the generator runs a partial Fisher–Yates shuffle over the pool's index positions: for position i it draws a uniform offset into the not-yet-fixed tail, swaps the two positions, and fixes position i. After k rounds the first k positions hold k distinct indices, and every ordered selection of k is equally likely. That is why a spin never repeats a name within one sex, and why a request for 20 names from a large pool takes 20 rounds plus any rejections — never a growing number of retries against duplicates.

The trace below runs the real uniformInt round by round on the 2025 girls' top-10 tier, a pool of 10 names, with the scripted bytes 9, 0, 4. Each round's span is one shorter than the last because one more position has been fixed.

The real sampleIndices with those bytes returns the index positions 9, 1, 6, and generateNames on the top-10 tier with those bytes returns Eliana (#10), Charlotte (#2), Isabella (#7) — the same rows, because it is the same code path the homepage uses. Only the byte source differs.

When fewer names come back than you asked for

The count control runs from 1 to 20. When the pool is smaller than the request, the generator draws the whole pool in shuffled order and states how many names matched, instead of topping the list up from outside your filters. The 2025 girls' top-10 tier has 10 names; a request for 20 returns 10. Under an all-zero byte source the shuffle is the identity, so they arrive in rank order: Olivia (#1), Charlotte (#2), Emma (#3), Amelia (#4), Sophia (#5), Mia (#6), Isabella (#7), Evelyn (#8), Sofia (#9), Eliana (#10).

Empty results are real results

Two different situations produce an empty list, and the generator tells them apart. The first is structural: the chosen tier begins past the era's committed depth, so no row could ever match. Selecting the uncommon tier in the Classic 1950s (1955 snapshot) era returns 0 rows with the reason tier-beyond-era and the depth 200 attached, so the message can say which era to switch to. The second is a plain no-match: the tier exists at that depth, but no name in the list passes every filter. Counting every letter, length and tier combination — 312 per sex per era — gives the picture below.

In the 2025 girls' list, the first empty combination in letter order is A + short (4 letters or fewer) + top 10 (ranks 1–10): the letter A has 170 girl names in that year's top 1,000, headed by Amelia at #4, and none of them meets that length and tier together. The engine returns 0 rows with the reason no-match. An empty result says nothing about names the SSA did not publish: names given fewer than 5 times in a year are excluded at the source, and anything ranked past the committed depth is outside these files.

Checking it yourself

The sampler takes its byte source as a parameter. In the browser it is crypto.getRandomValues; in the automated tests it is a scripted sequence, and the tests pin the exact index each sequence must produce. The draws on this page were produced the same way at build time: the scripted bytes went through the real uniformInt, sampleIndices and generateNames, and the build checks that the three agree before the page is written. If the committed data changes, every count, rank and index above changes with it, or the build fails. The methodology page holds the full conventions for ranks, counts and eras. The other guides are indexed at /guides/.

Frequently asked questions

Source: every name, rank, and count on this page comes from the U.S. Social Security Administration's national baby-names dataset (1955, 1965, 1975, 1985, 1995, 2005, 2015 and 2025 data, from Social Security card applications). It is public-domain U.S. government data; names given fewer than 5 times in a year are excluded by the SSA, spelling variants are counted separately, and the data covers U.S. births only. Full caveats on the methodology page.