Mock JSON Data Generator

Building a UI against three hand-typed records produces a UI that works for three hand-typed records. Realistic volume and realistic variation surface the layout, pagination, and performance problems that only appear with real data, and they surface them before a user does.

How to use it

1. Pick a schema: users, products, or orders.
2. Set how many rows you want.
3. Copy the generated JSON. Everything is produced in the page.

Why fake data beats no data

Placeholder text of uniform length hides most of the bugs you are trying to find. Every name being roughly eight characters means you never see what happens to a table when one is sixty. Every price being a round number means you never find the currency formatting bug.

Realistic generated data varies in the dimensions that break interfaces: name length, presence or absence of optional fields, string values containing apostrophes and non-ASCII characters, prices with awkward decimal parts, and dates spread across a range rather than clustered on today.

It also lets you work at volume. A list view that feels instant with ten records and unusable with two thousand is a common outcome, and the only way to find out early is to render two thousand.

The alternative is worse

The usual substitute for generated data is a copy of production. This is a bad idea for reasons that go beyond principle.

Under GDPR and comparable regimes, using production personal data in a development environment is processing it for a purpose the subject did not consent to. Development environments also have weaker access controls, less monitoring, and a habit of ending up on laptops and in ad-hoc database dumps, which is how a substantial proportion of breaches actually happen.

Generated data has none of those problems, and it has a practical advantage as well: you can produce the edge cases you need on demand rather than hunting for a production record that happens to exhibit them.

What synthetic data will not tell you

It is worth being clear about the limits, because generated data creates its own blind spots.

Things it does not reproduce:

• Realistic distributions. Real data is heavily skewed. A handful of customers place most of the orders, a few products account for most of the revenue, and a small number of records are enormous outliers. Uniformly random data is smooth, and smooth data hides the pathological cases.
• Referential integrity. Records are generated independently, so an order will not reference a user that also exists in your user set unless you wire that up yourself.
• Genuine dirtiness. Real data has duplicate accounts, half-completed records, values in the wrong field, encoding damage from a migration years ago, and entries created by a script that no longer exists. Generated data is clean, and clean data does not exercise your error handling.
• Query performance characteristics. Database planners choose plans based on statistics about data distribution. Uniform synthetic data produces different plans from skewed real data, so timings measured against it can be misleading.

Making it reproducible

Output here is freshly random on each generation, which is what you want for exploring. It is not what you want for a test suite, where a failure that only reproduces sometimes is worse than no test.

For automated tests, generate a dataset once, commit it as a fixture, and use that. When you need generated data inside a test run, use a seeded generator so the same seed always produces the same records, which keeps failures reproducible while still giving you variety.

At a glance

Frequently asked questions

Related tools