Fake Address Generator: Build Valid Test Addresses (2026)

Each result is assembled from a country definition, one of that country's five city fixtures, a street-name list, a building number, and a postal-code pattern. The generator picks a country, picks a city fixture inside it, builds a street line in the local order, and fills the postal code from the pattern. Nothing is sampled from a delivery database and nothing is copied from a real mailbox.

That gives two guarantees and two non-guarantees. Guaranteed: the format follows the country conventions, and the same seed returns the same address. Not guaranteed: that the street exists at that number, or that a non-US postal code maps to a real delivery area. For US ZIPs there is a separate existence check against a 40,979-row dataset on the postal-code checker. Outside the United States the check is structural only, and the site says so rather than implying more.

Address forms rarely test the address. They test the validation layer, the masking, the length limits, the country-to-region dependency, and the serializer that writes the row to the database. A fixture that is already malformed hides all of that. If your Canadian fixture is "123 Main St, Toronto, ON 12345", the form accepts a pattern that a real Canadian postal code can never match, and the bug ships.

The reverse failure is equally common. Teams hand-write a fixture that is real-looking but wrong for the country, then add a workaround in the validator to accept it. Six months later the workaround is load-bearing and nobody remembers why the German postal field allows letters. Generated data that follows the published patterns eliminates both directions of drift, as long as the generator itself is honest about what it knows.

Synthetic addresses belong in every layer below production: unit tests for parsers and validators, integration tests that write and read address rows, end-to-end tests that fill a checkout form, load tests that need volume without touching a real customer, and localized screenshot runs for a marketing page. They are also useful for fuzzing, because you can deliberately generate values at the boundary of a length limit or a character set.

They are the wrong tool for anything that depends on a real delivery point. Do not use them for fraud checks, identity verification, ban evasion, account farming, review manipulation, or testing a shipping integration end to end. A synthetic address has no mailbox, so any step that requires an actual carrier scan will fail, and using generated identities to obtain goods or services is fraud regardless of how the data was produced.

The generator covers 38 countries. Each country carries five city fixtures, so there are 190 city definitions in total, and every city knows its region code, its postal pattern, and the local street conventions. Coverage is weighted toward markets where address forms are actually built: North America, Western and Northern Europe, and the larger Asia-Pacific and Latin American markets.

Two countries in the set have no postal code at all: Hong Kong and the United Arab Emirates. The generator leaves the field empty for both rather than inventing a number. That is the correct behaviour. A form that marks postal code as required in those countries is broken, and a fixture that supplies a fake code will hide the defect until a real user hits it.

A generator is only as good as its country table. The patterns below are the ones that most often get flattened into a single US-shaped template. Notice that Japan reverses the order entirely, that the Netherlands puts letters after the digits, and that Brazil and Japan both use a hyphen that is conventional rather than structural.

Postal codes must be stored as strings. Germany, France, Spain, Italy, and Poland all issue codes with leading zeros, and an integer column silently turns 01067 into 1067. The same applies to Australian and Brazilian codes. If your schema has a numeric postal column, the fixture will expose it the moment you seed a German address.

A generator that returns a different address on every call is not a fixture, it is noise. Seeded generation fixes an input so the output sequence is stable across machines and across runs. Pass the seed explicitly in tests, log it with any generated dataset, and treat a change of seed as a change of fixture that needs review.

The practical pattern is to derive per-entity seeds from one parent seed, for example a hash of the seed and the record index. That keeps the dataset stable while still producing different values per row. It also makes failures reproducible: when CI reports a bad address, the seed plus the index is enough to regenerate exactly that row. Never derive the seed from the clock or from a random call, because that is how a flaky test becomes a permanent mystery.

These are two different claims and conflating them is the most common way a test suite lies to its owners. A structural check answers "does this string match the country pattern". An existence check answers "does this code appear in a reference dataset". The postal-code checker on this site does the first for every country and the second only for US ZIPs, where it consults 40,979 rows.

A structural pass tells you the form will not reject a well-formed value. It tells you nothing about whether a carrier can deliver to it, whether the street number is in range for that street, or whether the city matches the ZIP. Those require postal reference data that this site does not ship. Write your assertions to match the check you actually perform, or the test names will overpromise for years.

The site does not generate Social Security numbers, payment card numbers, IMEI or IMSI values, Bluetooth addresses, or device serial numbers. That is a deliberate boundary, not a missing feature. Those identifiers carry checksums, allocation registries, or legal restrictions, and a plausible-looking generated value is far more dangerous than an obviously fake one because it can pass a naive validator and end up in a screenshot, a ticket, or a commit.

The same boundary applies to contact data. Generated email addresses always use the reserved example.test domain, which can never resolve to a real mailbox. Generated phone numbers are limited to the NANP 555-0100 through 555-0199 block in the US and Canada, the range reserved for fictional use. If a workflow needs a card number or a tax identifier, use the official test values published by the processor or the tax authority, and never a value scraped from a generator.