Data & Methodology

Every profile FakeName Generator produces is fictional, but it is not fictional in a uniform way. Some fields are drawn from real public reference data so the record behaves correctly in software — a ZIP code a validator accepts, an area code that matches the city beside it. Others are invented outright so the record can never describe or reach a real person.

Which is which depends on the country, and in the US it depends on the city. This page states it precisely, names every source, and ends with a list of the defects we know about and have not fixed yet.

US addresses: what is real and what is invented

US profiles get the strongest guarantees, because they are the only ones backed by reference datasets. Everything below applies to the home page, the state pages, the city pages and US API calls.

Outside the United States

Twenty-eight of our thirty-seven other countries now get the same treatment as the US: the address is pinned to a real city, and the region, postal code and coordinates all follow from that one choice rather than being drawn independently. A German address names a real German city, its actual Land, and a postal code that genuinely belongs to it.

Two things still differ from a US address:

• The street is invented, exactly as in the US — the street name comes from a generic pool, not from that city's real streets.
• Only US and Canadian phone numbers come from a reserved range. For every other country the number is an ordinary locale-formatted number with no guarantee that it is unassigned. Do not dial one.

Four countries — the UK, Canada, the Netherlands and Ireland — publish only the geographic half of the postal code. That half is real and ties the code to the city; the remaining characters, which would identify a specific delivery point, are generated. It is the same split as a real US ZIP beside an invented street.

Nine countries are not pinned and still draw city, region and postal code independently, so those three need not agree with one another. Japan, China and Thailand are excluded on purpose: the available reference data is romanised, and pinning would turn a Japanese address into romaji, which is worse than the incoherence it would fix. Greece, Vietnam, Israel, Taiwan and Nigeria have no published postal dataset to pin against. Hong Kong has no postal code system at all, which is why that field is empty rather than invented.

Where the data comes from

How the output is checked

An identity is a pure function of its inputs: the same seed and the same options produce the same record every time. (The reference date is one of those options — the API pins it, so an API result is stable, while the on-page generator uses the current date, so birth years there shift with the calendar.) That makes the output testable, and these rules are written as automated tests rather than checked by hand:

• Every ZIP a city page emits must appear in that city's real USPS list.
• Every ZIP a state page emits must fall inside that state's documented USPS ranges.
• Every city with a verified area-code list must emit one of its own codes — never its state's wider set, which is how a Nashville code once reached a Memphis page.
• Two cities that share a name but sit in different states may not share a verified area code. There are two Auroras, in Illinois and Colorado, and no reference dataset can tell you which one a page means.
• A ZIP that takes no ordinary residential street mail — PO-Box-only, military, single-facility, or a campus counted entirely as group quarters — may not appear in any city or state pool. Twenty-four individually verified examples are pinned by name so the rule cannot quietly stop catching them.
• Every US phone number stays inside the reserved 555-01XX block, and every generated card number passes Luhn.
• A city page stays out of the search index until it has a hand-written, verified local content entry.

Limits we know about

This section exists because the alternative is worse. Treat it as the list of things not to rely on.

• Street names are generic, not local. They are plausible American-style street names, not the streets that exist in the city named beside them.
• Three cities borrow a neighbour's ZIPs. USPS files Bloomington MN, Lakewood CO and Parma OH under Minneapolis, Denver and Cleveland, so those pages draw their neighbour's codes.
• The delivery classification is inferred, not licensed. USPS sells the authoritative file; ours is derived from public census and postal signals. It is deliberately conservative, so it will drop some codes that do take street mail.
• Nine countries are still not geographically coherent — Japan, China, Thailand, Greece, Vietnam, Israel, Taiwan, Nigeria and Hong Kong draw city, region and postal code independently. See the section above for why each is excluded.
• The international phone format is omitted more often than you might expect, on purpose. We check every number against the country's published numbering plan and drop the phoneE164 field rather than emit a value we cannot stand behind. Some locales in the underlying library produce malformed numbers outright — Finland, Italy and Mexico are the worst, and for those the field is absent on most records. A length check also cannot catch every error, so treat the international format outside the US and Canada as best-effort rather than dialable.
• Email and username degrade for non-Latin locales. Japanese, Chinese, Korean, Russian, Ukrainian, Greek, Hebrew and Thai profiles lose the name-derived part and produce addresses like “91@example-domain”.
• Only the API takes a seed. The on-page generator seeds from the date and the bulk exporter mints a hidden seed per download, so neither can replay a specific profile. Row seeds in the API are suffixed per index, so an API row is not the same record as a bare-seed page.
• Coverage is deliberately narrow. US ZIPs are five digits with no ZIP+4, there are no PO-box-format street lines, no territory addresses, and no mode for deliberately malformed input — those fixtures you still write by hand.

How this is maintained

Reference datasets are refreshed when the upstream source changes materially — a new area-code overlay entering service, a postal-code release — and this page carries the date of its last substantive revision, as does every data page on the site. Corrections are made in the data files themselves so the generator, the public API and the on-page tables cannot drift apart. If you find something wrong, the contact page reaches a person, and it will be added to the list above until it is fixed.

What this data must not be used for

Generated identities are for building and testing software, filling demos, and declining to hand your real details to forms that have no need for them. They are not for:

• Receiving anything. The addresses point at no real building and US phone numbers ring nowhere. Shipping to one is a lost parcel.
• Identity verification or KYC. Submitting fictional details where a real identity is legally required is fraud, regardless of how valid the checksum is.
• Forged documents or identifiers. Producing an ID, a record or any instrument intended to pass as genuine.
• Impersonating a real person, or evading a ban, a trial limit or a service's terms.
• Financial crime. The card numbers are sandbox test values; they exist so a payment form can be exercised, not so a payment can be made, and never for laundering or obscuring funds.
• False statements in official contexts — governmental, medical, legal or employment.

The full terms are on the terms of use page, and what we do and do not collect from you is on the privacy policy.