Mock Data Generator: Create Realistic Test Data in Seconds

A dev or staging database needs rows in it before anyone can test anything, and there are really only two ways to get them: copy a slice of production, or generate them. Copying production is the path most teams fall into by default, and it's the one worth avoiding — a database dump or a scrubbed export usually still contains real customer names, emails, and addresses, sitting in a staging environment that almost never has the same access controls, audit logging, or network restrictions as production. That's not a hypothetical compliance problem; it's one of the more common ways real PII ends up somewhere it shouldn't. A mock data generator — sometimes called a fake data generator or test data generator — sidesteps the whole question by never touching production in the first place. You describe the shape of the data you need and it produces rows that look right without being anyone real.

There's a meaningful difference between data that's merely present and data that's realistic. Filling a name field with "asdf" or an email field with "[email protected]"satisfies a NOT NULL constraint, but it doesn't exercise anything a real value would. A name field padded with fifty rows of "a" never shows you that your UI truncates a long name mid-word instead of with an ellipsis. A column of identical "test"strings never shows you that your sort function breaks on ties, or that your search box can't handle a name with an apostrophe in it. An address field left as "123 Main St"fifty times over never surfaces the bug where your layout can't handle a genuinely long street address wrapping to a second line. Realistic fake data — varied lengths, plausible formats, actual entropy — puts pressure on the same code paths real users will, which is exactly what placeholder junk data was never designed to do.

The other property worth being precise about is reproducibility, and it hinges on one word: seeded. A seeded generator takes a seed value alongside your schema and uses it to drive the random number generator deterministically — the same seed and the same schema produce the exact same rows, every single time, on any machine. A non-seeded generator produces a fresh, different dataset on every run, which sounds harmless until someone files a bug report. “Row 47 breaks the date picker” is only a useful bug report if a teammate can actually generate a row 47 that matches — with a seeded dataset they run the same schema and seed and get the identical row back; with an unseeded one, row 47 was a one-time artifact that no longer exists anywhere. Seed data used in automated tests has the same requirement for a different reason: a test suite that generates new random rows on every run will occasionally fail nondeterministically on some edge case it happened to roll, and nobody will be able to reproduce the failure locally. Seeding turns “random” into “random once, then fixed,” which is what both debugging and testing actually require.

A one-line-per-field schema is the fastest way to describe the shape you want: a field name, a type, and any constraints, one per line, with no boilerplate around it. The generator maps each line to a realistic-looking value and repeats that for as many rows as you ask for.

id: uuid
name: full_name
email: email
signup_date: date(2023-01-01, 2025-12-31)
plan: enum(free, pro, enterprise)
is_active: boolean

[
  {
    "id": "d3f1a9c2-7b4e-4a91-9c3d-2e8f5b0a1c67",
    "name": "Priya Chandrasekaran",
    "email": "[email protected]",
    "signup_date": "2024-03-11",
    "plan": "pro",
    "is_active": true
  },
  {
    "id": "9a2e7f10-4c8b-4d3e-b1a5-6f0d2c9e8b34",
    "name": "Marcus O'Donnell",
    "email": "[email protected]",
    "signup_date": "2023-08-27",
    "plan": "free",
    "is_active": false
  }
]

Notice the second row: a name with an apostrophe in it. That's not an accident of the example — realistic name generation naturally produces the punctuation, casing, and length variation that a hand-typed placeholder set almost never does, which is precisely the point made above about catching bugs before real users do.

The right export format depends entirely on where the data is going next, not on any inherent superiority of one format over another.

• JSON or NDJSON — for feeding rows directly into an app or an API. JSON works well for a single request body or a fixture file; NDJSON (one JSON object per line) is the better fit for streaming rows into a log pipeline or a bulk-ingest endpoint that reads line by line instead of parsing one large array.
• CSV — for spreadsheet tools, or for the bulk-import UI that half of internal admin tools ship with. If a product feature accepts a CSV upload, generating the seed data in that exact format is faster than generating JSON and converting it.
• SQL INSERT statements — for seeding a database directly, with no intermediate step. You paste the statements into a migration, a seed script, or a psql/mysql session, and the rows exist in the table with correctly quoted and escaped values.

Every row also needs a primary key, and uuidis the default choice for the id field in the schema above precisely because it's collision-free without coordinating a counter — the same reasoning covered in more depth in the UUID Generator guide, which is worth reading if you're deciding between a UUID and an auto-incrementing integer for seed rows.

GenKitLab's Mock Data Generator takes a one-line-per-field schema like the one above and produces realistic seed rows exported as JSON, NDJSON, CSV, or SQL inserts — seeded, so the same schema and seed reproduce the exact same output every time. It runs entirely in your browser: nothing you type is uploaded anywhere, which matters here too, since a schema itself can sometimes describe internal field names you'd rather not send to a server.