Random Names for Test Data

Rather than assert that international names are awkward, we measured the pools this generator draws from. The method: 20,000 given-name plus surname pairs per locale, generated with faker 9.9.0 on 22 August 2026, counted for the characteristics that tend to break validation. "Full name length" below is the given name, one space, and the surname — the middle initial this site adds for some locales is excluded so the numbers describe the name itself.

Spanish is the row worth reading twice. Every single surname drawn contained a space, because the Spanish convention carries two surnames, the paternal followed by the maternal. The longest record in that sample ran to 48 characters. A schema with one 20-character surname column is not tight for Spain; it is incorrect for it, and the failure shows up as silent truncation rather than as an error.

Japanese fails in the opposite direction: three characters, including the space. Minimum-length rules of five or six characters are a common anti-spam heuristic on name fields, and they reject real Japanese names outright. Dutch surnames carry a particle — van, de, van der — in 43.7% of draws, which breaks the very common shortcut of splitting a full name on whitespace and treating the last token as the family name.

Turkish is the row that catches comparison logic rather than storage: 65.6% of the sampled names contained a dotted or dotless I. Turkish uppercases "i" to "I" with a dot and lowercases "I" to a dotless one, so a case-insensitive comparison that follows the machine's locale can decide that two spellings of the same name do not match. In JavaScript that is the difference between toLowerCase, which ignores locale, and toLocaleLowerCase with a Turkish tag, which does not.

And English is the row that flatters you. Zero non-ASCII characters in 20,000 draws, which means a fixture set built entirely from English names never exercises encoding, normalization or font fallback at all. Whatever else you do, do not let en-US be the only locale your name handling has seen.

The value of a varied fixture set is that each shape maps to a distinct class of defect, so a small set chosen on purpose beats a large one chosen at random. The table below pairs the shapes above with the failure they usually surface first, using examples that genuinely appear in the pools this page generates from.

Two of these deserve emphasis because they are so often missed. Accented characters interact with Unicode normalization: the same name can be encoded with a precomposed character or with a base letter plus a combining accent, and the two are visually identical but not equal as byte strings, so a lookup can fail against a value that looks correct on screen. And a name that is short is as dangerous as one that is long — length validation written as a minimum is rarely tested against the shortest real input.

A suite that generates fresh random names on every run has a failure mode of its own: when it fails, you cannot reproduce it. The fix is to generate once and commit the result, which is why the public JSON API accepts a seed. The same seed and the same parameters return byte-identical records, so a fixture file can live in the repository beside the test that reads it.

A request looks like https://fakenamely.com/api/v1/name?count=25&country=jp&seed=checkout-suite-v3 — no key, no sign-up, up to 100 records per call, and format=csv if you would rather have columns than JSON. For a larger set, the bulk exporter goes to 100,000 rows and writes CSV, JSON or SQL INSERT statements directly.

Be aware of the boundary here, because it is the sort of detail that quietly wastes an afternoon: only the API takes a seed. The Generate button on this page mints a fresh random seed each time by design, and the sample rendered when the page loads rotates daily. If reproducibility matters, take the data from the API.

An identity here is a pure function of a seed string. The seed is hashed to a 32-bit integer with cyrb53, that integer seeds an isolated pseudo-random generator, and the field builders consume it in a fixed order — prefix, given name, middle name, surname, then everything downstream. Nothing reads the clock or a global random source, which is why the same seed produces the same name on our server and in your browser.

The pools themselves come from Faker's locale datasets: lists of given names and lists of surnames, per language. The two are drawn independently, so the pairing is a coincidence of the draw rather than a record copied from anywhere. No registry, electoral roll, phone book or leaked dataset is used, and no name here is a lookup of a real person.

Middle names are the one place where a fallback used to show. Faker ships middle-name data for only a few locales, so for the rest the request resolves through English — which on a Latin-script name is merely unusual and on a non-Latin one is incoherent. Japanese profiles were rendering as a Japanese given name and surname with an English middle initial wedged between them, and Japanese names have no middle name at all. The generator now drops a middle name whose script does not match the given name, while keeping the genuine ones: Russian and Ukrainian ship real patronymics, so those profiles still carry a middle name, written in Cyrillic like the rest of the record.

One limit to know before you build assertions on it: names are assembled in Western order, given name first, even for countries that conventionally write the family name first. The given name and surname are always correct in their own fields — the name API returns each part separately — so if your test depends on order, compose the display string from those rather than parsing the full name. The complete list of what is real, what is invented and what is known to be wrong lives on the methodology page.