Mock Data Generator
Generate realistic fake test data — names, emails, addresses and more — as CSV or JSON, so you never have to test against real records.
Fields to include:
Generated data repeats itself far sooner than you would guess
Pick names at random from a list of a thousand and it feels safe for a few hundred rows. It is not. The chance of a repeat passes even odds at 38 rows, because what grows is not the number of rows but the number of pairs of rows — n rows give n(n−1)/2 chances to collide, and that overtakes the pool size very quickly.
| Rows generated | Chance of at least one repeat | Distinct names expected |
|---|---|---|
| 10 | 4.4% | 10.0 |
| 25 | 26.1% | 24.7 |
| 50 | 71.2% | 48.8 |
| 100 | 99.4% | 95.2 |
| 250 | 100.0% | 221.3 |
Twenty-five rows already carries a 26% chance of a duplicate name. A hundred rows is 99.4% — effectively certain. And drawing a thousand times from a thousand names yields only about 632 distinct ones, so roughly a third of the list never appears at all while others appear three or four times.
This is the same arithmetic as the birthday problem, where 23 people give an even chance of a shared birthday. It is worth checking a generator against that answer, because it is the one case everybody already knows: the numbers here reproduce it exactly.
A bigger list does not fix it
The obvious response is to use a longer name list. The square root is what stops that working.
| Pool size | Rows before a 50% chance of a repeat | 1.18 × √pool |
|---|---|---|
| 365 | 23 | 23 |
| 1,000 | 38 | 38 |
| 10,000 | 119 | 118 |
| 100,000 | 373 | 373 |
| 1,000,000 | 1178 | 1178 |
The halfway point sits at about 1.18 times the square root of the pool, at every scale — the approximation is never more than one row out. So making the list a hundred times longer only makes the safe run about ten times longer. Going from a thousand names to a hundred thousand moves the danger point from 38 rows to 373, which is better but is not the qualitative fix people expect for a hundredfold increase.
The actual fix is to stop drawing at random. If a field needs to be unique, get uniqueness by construction: shuffle the pool and deal from it without replacement, or append a row counter to each value. Random draws give you uniqueness by luck, and the luck runs out at the square root of your list — which is a much smaller number than the list.
This matters mainly because of how it fails. A test suite that assumes generated records are distinct — a unique index, a lookup expecting exactly one row — passes on ten rows and fails on a hundred, intermittently, with a different name each run. That is among the more expensive classes of bug to track down, and it is entirely avoidable at generation time.
How to use
- Choose the fields your schema actually needs.
- Set how many rows to generate — more than you think.
- Download as CSV or JSON, or copy it straight out.
- Include some awkward values deliberately, not just tidy ones.
- Never substitute real customer records for this.
Frequently asked questions
Why not just copy production data into my test environment?
Because it puts real people's information into environments with weaker controls, and it is a genuine legal exposure under data protection law. Test databases get shared freely, backed up carelessly and left running for years — and breaches of them are common precisely because nobody treats them as sensitive.
Is anonymised production data safe to use instead?
Considerably less than people assume. Re-identification from supposedly anonymised datasets has been demonstrated repeatedly, particularly where dates of birth, postcodes and rare attributes survive the process. Properly generated synthetic data sidesteps the question entirely.
What makes test data realistic enough to be useful?
The edge cases. Names with apostrophes and accents, very long addresses, empty optional fields, unicode beyond the Latin alphabet and outright duplicates all expose bugs that a neat generated set will never touch. Data that is too tidy passes tests that real input would fail immediately.
Do the generated email addresses work?
No, and that is deliberate. Generated addresses use reserved example domains that cannot receive mail, which prevents a test run accidentally sending messages to a real person. That failure has happened often enough at real companies to be a recognised category of incident.
Does anything get uploaded?
No. Generation happens entirely in your browser, so nothing is transmitted and no account is required at any point.
How much data should I generate?
Enough to be representative, which is almost always more than a handful of rows. Performance problems, pagination bugs, sort instability and timeout errors only appear at volume, and a test set of ten rows conceals every one of them.
Should the data be reproducible between runs?
For automated tests, usually yes — a fixed seed makes failures reproducible, which is the whole point of a test suite. For manual exploration, fresh random data each time is more useful because it surfaces cases a fixed set would never produce.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.