Generate Realistic Customer Data: Names, Addresses & More

"John Doe, 123 Main St, 10001 New York" is fine for smoke tests – but the moment you design a form, mock an invoice in production or demo a feature to a customer, you need realistic customer data. This article is about the how: without GDPR risk, without real people, but with enough variation for actual testing.

Why dummy data falls short

Layout edge cases: long names (von Hohenzollern-Sigmaringen), umlauts, hyphens – things John Doe does not have, but which can break your UI.
Validation logic: ZIP checks, IBAN validation, German phone formats – you only find bugs with realistic values.
Demo credibility: a pitch with 10 identical "John Does" looks cheap; 10 plausible names look like a real system.

What a realistic customer record contains

Field	Example	Watch out for
Salutation	Herr / Frau / Divers (DE), Mr. / Ms. (EN)	Neutral options too
First name	Lukas, Sophie, Mehmet	Statistically plausible distribution
Last name	Weber, Schmidt, Yıldız	Include umlauts and non-ASCII
Street + no.	Lindenstraße 42a	Test house number suffixes
ZIP + city	80331 München	Plausible ZIP → city mapping
Email	lukas.weber@example.de	Use `example.de/com/org` only (RFC 2606)
Phone	+49 30 1234567	E.164 international format
Birthdate	1988-04-12	Distributed across a realistic age range
IBAN	DE89 3704 0044 0532 0130 00	Valid check digit, not real

GDPR: what still counts as "personal data"?

In short: data that makes a person identifiable falls under GDPR – even if you use it "only for testing". In practice:

Never copy production exports into dev or staging environments. Not even "pseudonymized" if back-tracing is possible.
Fictitious names from a statistical distribution are safe – even if a real person happens to share the name. The key is that the dataset is not derived from real data.
For emails use the reserved domains per RFC 2606: example.com, example.org,example.de. Guaranteed not to have mail servers.

Generate, don't type

With the test data generator you pick the fields you need, choose a count (10, 100, 10 000…) and export as JSON, CSV or SQL INSERT. German names and addresses are pre-configured, including umlauts and a plausible ZIP → city mapping.

Sample output (JSON)

[
  {
    "anrede": "Frau",
    "vorname": "Marie",
    "nachname": "Schmidt",
    "strasse": "Lindenstraße 42",
    "plz": "80331",
    "ort": "München",
    "email": "marie.schmidt@example.de",
    "telefon": "+49 89 1234567",
    "geburtsdatum": "1989-07-14",
    "iban": "DE89370400440532013000"
  }
]

When you need more than 100 records

For performance tests or reports you quickly need 10 000+ rows. Two tips:

Deterministic seed: a fixed seed value yields reproducible data – important when debugging bugs by specific rows.
Stream, don't load into memory: for large volumes export as CSV and stream row-by-row into the DB (COPY FROM on Postgres, LOAD DATA INFILE on MySQL).

In practice: 500 demo customers in 2 minutes

Open the test data generator.
Pick fields: salutation, name, address, email, phone, birthdate, IBAN.
Set the count to 500, country "Germany".
Export as JSON or CSV.
Import into your database or demo system.

Done: a convincing demo dataset without a single real person in it.