Most address forms are a United States address form wearing a country dropdown. Street, city, state, ZIP; the state is a required select, the postal code is validated as five digits, and the labels stay in place when the country changes. It works for one country and degrades from there, and the degradation is invisible in testing because the fixtures were American too.
The honest way to find those failures is to feed the form addresses from countries that are shaped differently. A Dutch postal code is four digits, a space and two letters. A Japanese one is three digits, a hyphen and four more, conventionally printed after a postal mark. Ireland had no postcodes at all until Eircode arrived in 2015, and Hong Kong still has none — there is no field to fill, and a form that requires one cannot be completed by anyone who lives there.
The random address generator behind this page produces addresses for 38 countries, and it pins them: a real city is chosen first, and the region, postal code and coordinates are all derived from that choice rather than drawn independently. That is what makes a record usable as a validation fixture — the fields agree with each other in the way a real address's fields agree, so when your form rejects one, the rejection is about your rules.
What the generator will not do is invent a postal code for a country that has none, or dress a partial code up as a complete one. Where only the geographic half of a code is published, that half is real and the rest is generated, and where a country has no system at all the field comes back empty with the reason attached. Those two behaviours are the point of the page: a fixture that lies about what is real is worse than no fixture.
The assumptions a US-shaped form makes
Five assumptions account for most international address failures, and each one is easy to test once you have fixtures that violate it. That the postal code is required and numeric. That a state or province is required and comes from a fixed list. That the postal code is a fixed length. That the address can be uppercased, ASCII-folded or split on commas without loss. And that the field order on screen matches the order the address is written in.
The postal code assumption is the expensive one. A pattern of five digits rejects the United Kingdom, Canada, the Netherlands, Ireland, Japan and Brazil outright, and quietly mis-accepts Brazil's eight-character CEP by matching only its first five characters. Making the field optional is not the fix either, because the same form then accepts a US order with no ZIP. The rule has to be per country, which means the form needs a country-aware validator and the test suite needs a fixture per shape.
The required-region assumption fails differently: many countries have administrative divisions that are simply not part of a postal address, so a required dropdown forces the user to pick something arbitrary, and whatever they pick is then stored and shipped to a carrier. Hong Kong is the clean example, and it is also the clean test — if your form can complete a Hong Kong address with no postal code and no state, it has probably stopped hardcoding the United States.
The formatting assumptions are the ones that survive review and fail in production. USPS Publication 28 defines a complete address as one that has all the elements needed to match against the Postal Service's own ZIP+4 and city-state files, which is a lookup rather than a pattern — a well-formed address can still be an address that does not exist. Meanwhile the Universal Postal Union publishes each member country's addressing format, and the line order in those documents varies more than a form designer would guess.
Which countries break which assumption
The table below is the shortest useful tour. Every shape in it is one this generator produces, so each row is a fixture you can pull in a couple of seconds rather than a hypothetical.
Two rows deserve a note. Ireland's Eircode is a seven-character code in two parts, a three-character routing key and a four-character unique identifier, and it was introduced in 2015 — so historical data from Irish customers legitimately has no postcode, and a validator that requires one will reject records that were correct when they were captured. And Hong Kong has no postal code system whatsoever: the correct value is nothing, not a placeholder, not 00000, and certainly not a number invented to satisfy a required field.
The United Kingdom, Canada, the Netherlands and Ireland share a property worth understanding before you build assertions on their codes here: published reference data covers the geographic half of the code — the part that ties it to a place — while the remaining characters identify a specific delivery point. This generator emits the real geographic half and generates the rest, which keeps the code format-valid and tied to the right city while making sure it does not name a real doorstep.
Postal-code shapes, and what a five-digit rule does to them
| Country | Shape | Example | What a US-shaped form does |
|---|
| United States | 5 digits | 43215 | Accepts — this is the shape it was built for |
| Germany, France, Spain, Italy, Mexico | 5 digits | 80331 | Accepts, and often mislabels the field as ZIP |
| Australia | 4 digits | 3000 | Rejects: one digit short of the hardcoded length |
| Japan | 3 digits, hyphen, 4 digits | 100-0001 | Rejects: the hyphen fails a digits-only rule |
| Brazil | 5 digits, hyphen, 3 digits | 01310-100 | Silently mis-accepts the first five characters as if they were the whole code |
| United Kingdom | Variable alphanumeric, internal space | EC1A 1BB | Rejects: letters, variable length and a space |
| Canada | Alternating letter and digit, 6 characters | M4B 1B4 | Rejects, and case-folding the value loses nothing but often breaks the pattern anyway |
| Netherlands | 4 digits, space, 2 letters | 1011 AB | Rejects: the trailing letters are part of the code |
| Ireland | 3-character routing key, 4-character identifier | A65 F4E2 | Rejects — and pre-2015 Irish records have no code at all |
| Hong Kong | No postal code system | (empty) | Cannot be completed: the field is required and there is nothing to enter |
Every shape here is one this generator produces. The pattern column is the format, not a validator you should copy — a real validator does a lookup, because a well-formed code can still be a code that was never issued.
Building a fixture set that covers the shapes
You do not need one fixture per country. You need one per shape, plus the countries you actually operate in. A defensible minimum is: the United States for five digits, the Netherlands for digits-plus-letters, the United Kingdom for a variable-length alphanumeric code with an internal space, Japan for a hyphenated numeric code, Brazil for an eight-character code whose first five look like a US ZIP, Ireland for a code that only exists after 2015, and Hong Kong for no code at all.
Pull them from the JSON API in one pass and commit the result. A seeded call returns byte-identical records, so the fixture file is stable, and the country parameter accepts either a slug or an ISO 3166-1 alpha-2 code — for example https://fakenamely.com/api/v1/address?country=nl&count=5&seed=address-form-v2, with format=csv if you would rather have columns. The bulk exporter handles the larger sets, up to 100,000 rows.
Then test the rejections as carefully as the acceptances. A validator that accepts every fixture is not obviously correct — it may be accepting everything. Pair each valid fixture with a deliberately broken sibling: a Dutch code with the letters missing, a UK code with the space in the wrong place, a five-digit number where an eight-character CEP belongs. The generator gives you the valid half; the invalid half is a hand-written list, and it is short.
How these addresses are generated
Generation starts from a place rather than from fields. The generator picks a real city, and the region, postal code, telephone area code and coordinates are all derived from that single choice — which is why the fields agree. Before that change the United States path drew city, state and ZIP independently, and the result was records like an invented town in California carrying a Michigan ZIP: measured over 400 records, 19% of those postal codes were real and 1% agreed with the state printed beside them.
For the United States the postal codes come from the GeoNames postal dataset, published under CC BY 4.0, filtered to codes that take ordinary residential street mail — so PO-Box-only, military and single-facility codes are excluded from the pools. Telephone area codes come from the North American plan's rate-centre data for that same city, not from its state's wider list. Twenty-eight of the other countries are pinned the same way against their own city data; nine are not, and those nine are named on the methodology page rather than left for you to discover.
What stays invented is the delivery point. The street name comes from a generic street-name pool rather than that city's real streets, and the house number is a random value between 1 and 9989. So a generated address is a real city, a genuinely valid postal code for it, and a street that is not expected to exist there — format-valid and region-consistent, deliberately not deliverable.
These rules are enforced as tests rather than asserted in prose: every postal code a city page emits has to appear in that city's real published list, every state-page code has to fall inside that state's documented ranges, and a code that takes no ordinary street mail may not appear in any pool — with two dozen individually verified examples pinned by name so the rule cannot quietly stop catching them.
What one generated address record actually contains
| Field | Real or invented | Note |
|---|
| City | Real | Chosen first; everything else is derived from it |
| Region, state or province | Real | The region that city is actually in, for the pinned countries |
| Postal code | Real | Genuinely issued for that place, filtered to codes that take ordinary street mail |
| Street name | Invented | From a generic street-name pool, not that city's real streets |
| House number | Invented | A random number between 1 and 9989 |
| Telephone area code | Real | Drawn from that city's own rate centre in the United States and Canada |
| Coordinates | Approximate | A random point near the city centre — it locates the region, not the address |
| Country and country code | Real | ISO 3166-1 alpha-2 |
The split is deliberate: the parts a validator checks are real, and the part that would identify a household is not.