Skip to main content

Fake Data Generator

English

Generate sample personal data for testing.

All calculations performed locally in your browser. No data sent to server.

Results are for informational purposes. Verify results with other sources.

The most dangerous test data is the tidy kind

Generated records let you fill a database, load-test an endpoint or build a screen before any real user exists — without copying production data into a laptop. But a generator that only emits neat ASCII names and well-formed postcodes will happily let a field that breaks on O'Brien reach production.

How it works

  • Produces realistic-looking names, emails, addresses, phone numbers, dates and identifiers in bulk.
  • Exports as JSON or CSV so the output can be seeded straight into a database or fixture file.
  • Generates volumes large enough to expose pagination, indexing and rendering problems that ten rows never will.
use generated data when you need
  volume        — thousands of rows to test pagination and query plans
  safety        — no real personal data on a developer machine
  repeatability — the same seed gives the same set every run

realistic ≠ tidy: real data has apostrophes, accents and empty fields

Worked example

Seeding a user table before the product has any users.

  1. generate 5,000 rows rather than 10 — pagination and slow queries only appear at volume
  2. include names that break naive code: O'Brien, Łukasz, José, 名字
  3. include an email with a plus tag and one at the 254-character limit
  4. leave some optional fields genuinely empty rather than filling every column
  5. fix the seed so a failing test reproduces exactly

A dataset that exercises the awkward cases on your machine instead of discovering them from a customer. The apostrophe alone catches unescaped SQL, broken CSV export and mangled display in one row.

Reading the result

  • Never seed with a copy of production. Beyond the legal exposure under GDPR, real records leak onto laptops, into backups and through screen shares, and there is no way to recall them afterwards.
  • Generated data is not anonymised data. If you derive rows from real ones by shuffling or masking, re-identification is often possible; synthetic records generated from nothing carry no such risk.
  • Seed your generator when tests depend on the output. Unseeded randomness produces suites that fail once a week and pass on retry, which teaches people to ignore failures.
  • Keep obviously fake domains — example.com is reserved for exactly this — so a misconfigured job cannot email a real address.

Common questions

How many rows should I generate?
Enough to break something. Ten rows prove a screen renders; a few thousand reveal missing indexes, unbounded queries and pagination that falls apart on the last page. Match production's order of magnitude if you can.
Can I use it for load testing?
Yes, and it is one of the better uses — but vary the values. Ten thousand identical requests measure your cache, not your system; distinct records exercise the paths a real workload actually takes.

Sources