How to Generate Realistic Fake Address and Locale Data for 50+ Countries

Address forms that only get tested against US-style addresses break the moment a real user from the UK, Japan, or Germany tries to sign up — different countries have different field orders, different postal code formats, and some don't use a "state" field at all. Testing with locale-aware fake data catches these bugs before they reach international users.

Why "One Address Format" Testing Isn't Enough

A form hardcoded around US conventions — Street, City, State (2-letter), ZIP (5 digits) — will mishandle addresses from most of the world:

• UK postal codes are alphanumeric (SW1A 1AA), not 5 digits.
• Japan writes addresses largest-unit-first (prefecture → city → block), the reverse of Western convention.
• Many countries have no "state/province" concept at all (Singapore, most small nations) — a required state field silently blocks signup for these users.
• Postal code length varies — Germany uses 5 digits, Canada uses an alphanumeric pattern (A1A 1A1), Ireland's Eircode is a 7-character alphanumeric code.

Generating Locale-Specific Fake Addresses with Faker.js

Faker.js supports dozens of locales, and switching locale changes not just names but address formatting conventions to match.

import { fakerEN_GB, fakerJA, fakerDE } from '@faker-js/faker'

const ukAddress = {
  street: fakerEN_GB.location.streetAddress(),
  city: fakerEN_GB.location.city(),
  postcode: fakerEN_GB.location.zipCode(), // e.g. "SW1A 1AA"
}

const japanAddress = {
  prefecture: fakerJA.location.state(),
  city: fakerJA.location.city(),
  postcode: fakerJA.location.zipCode(),
}

Generating a batch across several locales at once — rather than one locale repeated — is the fastest way to build a realistic international test suite for a signup or checkout form.

Structuring Your Address Schema to Support Multiple Countries

Rather than a fixed street/city/state/zip shape, a schema that supports international addresses generally needs more flexible field naming:

{
  "addressLine1": "10 Downing Street",
  "addressLine2": "",
  "locality": "London",
  "administrativeArea": "",
  "postalCode": "SW1A 2AA",
  "countryCode": "GB"
}

Using generic field names (locality instead of city, administrativeArea instead of state) — the convention used by Google's own address APIs — avoids baking US-specific assumptions into your data model from the start. You can shape sample data around exactly this structure using Dummy JSON Generator when you don't need Faker's locale-specific formatting logic and just need the field shapes populated.

Testing Postal Code Validation Correctly

If your form validates postal codes with a regex, test it against multiple countries' real formats, not just your home country's:

The Bottom Line

If your app serves users outside a single country, test address forms with locale-specific fake data — not just repeated US-style examples — and structure your schema around generic field names from the start so adding a new country later doesn't require a data model rewrite.