Random Address Generator

Why Use Generated Addresses in Testing

Copying a real customer's address into a staging database, a bug ticket or a demo is easy, and it is exactly the kind of data handling privacy law cares about. Under the GDPR, a postal address tied to a person is personal data, and test environments are not exempt: data minimisation and purpose limitation apply there too.

• Tickets travel: a bug report gets pasted into chat, linked from pull requests and exported to other tools. Anything in it, including a screenshot of a filled-in form, spreads with it.
• Staging is softer: test systems usually have wider access, lighter monitoring and longer retention than production. Real records there add risk without adding test coverage.
• Demos get recorded: sales demos, onboarding videos and documentation screenshots end up public. A generated address looks real on screen without pointing at anyone.
• Format still matters: placeholder text like "test test 123" never exercises your validation. Generated addresses follow each country's real postal code format and line order, so parsers, formatters and shipping logic get a realistic workout.

If a bug only reproduces with one customer's data, rebuild the shape of that record (same country, same field lengths, same special characters) with generated values instead of copying the record itself.

How Each Address Is Built

• Real places, matched: every city comes from a curated list with its real state, province or region and postal codes that belong to it. That means full ZIP codes in the US, real postcode districts in the UK, real forward sortation areas (the first three characters) in Canada, and real postal codes in Germany, Spain, France and Australia.
• Valid but random endings: in the UK and Canada the last three characters of the code are random but follow the official pattern, so the full code may not be an existing delivery point.
• Plausible streets: street names are built from common local patterns such as Maple Avenue, Station Road, Lindenstraße, Calle Mayor or rue de la République, with house numbers and unit lines in local style. A given street and number may or may not exist.
• Phone numbers nobody owns: phones come only from ranges reserved for fiction in the US, Canada, the UK, Australia, Germany and France. Spain has the option switched off because we could not confirm a reserved range.
• Emails at reserved domains: every email uses example.com, example.org or example.net, which RFC 2606 reserves for documentation. Nobody can register them, so no real inbox sits behind them. Emails are unique within a batch, which helps when you test a unique-email constraint.
• Secure randomness: every choice uses the browser's crypto.getRandomValues, so batches don't fall into predictable patterns.

Address Formats by Country

The generator prints each address in the line order the local postal service expects. Here is what changes from country to country, listed after the recipient's name:

Germany and France leave the region out of the postal address entirely, and in the UK the county is optional. A form that makes State mandatory for every country rejects perfectly valid addresses from those places.

Edge Cases QA Should Test in Address Forms

Address forms fail in the same handful of ways. Generate a batch for each country you ship to and check these:

• Long street names: Avenida de los Reyes Católicos or Hans-Böckler-Straße hit tight length limits and wrap badly on labels. Check everywhere the address lands: the form, confirmation emails, invoices, PDFs and any shipping or payment API, which often allows fewer characters than your own form.
• Non-ASCII characters: follow ß, ñ, é and ü from input to export. A UTF-8 value read as Windows-1252 turns München into München. Check case handling too: in JavaScript, "Straße".toUpperCase() returns "STRASSE", which can break exact-match comparisons.
• Apartment and unit lines: make sure the optional second line survives every handoff. Line order differs too: in the UK and France the flat or apartment line sits above the street. Spanish addresses put floor and door on the street line, German ones add the apartment or floor after the house number with //, and in the US, Canada and Australia the unit goes on the street line as well.
• Postal codes with letters and spaces: UK postcodes and Canadian postal codes mix letters and digits around a space. Accept lowercase input and a missing space, then normalise (sw1a1aa becomes SW1A 1AA). Never use type="number" for a postal code field.
• Leading zeros: Boston (02108), Dresden (01067), Barcelona (08001), Nice (06000) and Darwin (0800) all start with a zero. Store postal codes as text, never as integers. Excel drops the zero when you double-click a CSV, so import it through Data, From Text/CSV and set the column type to Text.
• Addresses without a state line: a required State dropdown blocks German and French users. Make the field, its label and its validation depend on the selected country.
• Autofill and autocomplete: use the standard tokens (name, address-line1, address-line2, address-level2 for the city, address-level1 for the state, postal-code, country, tel, email) and check that browser autofill fills the right boxes. Then switch the country after autofill and confirm the labels and validation update.
• Apostrophes and hyphens: St. John's, O'Brien and Saint-Étienne are in the dataset on purpose. They catch broken escaping in SQL, HTML and CSV, and validation that only allows letters.