Fake Data Generator
Generate realistic test data — names, emails, addresses, and more.
The seed is shown so a dataset is reproducible: the link carries it, so sending someone this URL gives them the exact same rows. Clear the field or press Generate for fresh data.
Generate fake test data — JSON and CSV
Create realistic-looking test records for development, demos, or database seeding.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Populating a development database with realistic-looking records.
- Producing screenshots for documentation without exposing real customers.
- Generating a dataset to test pagination, sorting and search behaviour.
- Creating input that exercises name and address parsing.
- Producing a demo dataset for a presentation.
How it works in practice
A worked example
A test failed on a generated dataset and you need exactly the same rows back in order to debug it.
Fields: id, name, email, job Count: 3 Format: json Seed: 424242
[
{
"id": 1,
"name": "Grace Lopez",
"email": "[email protected]",
"job": "DevOps Engineer"
},
{
"id": 2,
"name": "Ella Johnson",
"email": "[email protected]",
"job": "Scrum Master"
},
{
"id": 3,
"name": "Felix Scott",
"email": "[email protected]",
"job": "UX Designer"
}
]Paste that seed back and the same three people come out, on any machine, for as long as the generator itself is unchanged. A fresh generate draws a new 32-bit seed from the browser's cryptographic random source, shows it in the field and carries it in the page address — so a link to a fixture that broke something reproduces the fixture rather than describing it. Move the seed by one and every value changes, because all the fields draw from one stream and shifting the first draw shifts everything after it.
The edge case that catches people
Now look at the domains. Two of those three addresses are at mail providers that really exist, because the generator picks from a list of the ones people actually use and only one entry in it is the reserved example.com. So a record that looks obviously invented can still be a deliverable address, and a test that accidentally sends mail arrives in somebody's inbox rather than bouncing. The names collide with real people for exactly the same reason. Rewrite the domain to something unroutable before this data goes anywhere near a sender.
When not to use this tool
Not for volume, and not where the values have to be valid. Everything is built in the tab, so a million rows is a memory problem rather than a dataset and a staging database wants a script running server-side. The values are also shaped to look right rather than to pass checks — a phone number is plausible digits rather than a real numbering plan, and nothing here emits a card number that satisfies a checksum or a postcode that resolves. If your code validates a field, that field needs a generator which knows the rule it is validating.
Frequently Asked Questions
- Why not just copy production data into testing?
- Because it is a serious compliance problem. Under GDPR, personal data in a test environment carries the same obligations as production, and test environments are typically less protected. Synthetic data has no such obligations.
- Is pseudonymised data the same as synthetic?
- No, and the distinction is legally significant. Pseudonymised data is still personal data under GDPR because re-identification is possible. Genuinely synthetic data was never about a real person, so it falls outside scope.
- What makes good test data?
- Awkward cases, not tidy ones. Apostrophes in names, non-ASCII characters, very long strings, empty optional fields and boundary values. Data that is uniformly well-formed hides exactly the bugs testing should find.
- Should generated data be deterministic?
- For test fixtures, yes — a seeded generator makes failures reproducible. Non-deterministic data produces flaky tests that pass and fail with no code change, which is worse than weaker coverage.
- Does it maintain referential integrity?
- Only if you generate related records together. Independently generated rows produce orphaned foreign keys, which fail on insert — so parent records must exist before the children that reference them.
- Does synthetic data remove privacy obligations entirely?
- Only if it is genuinely synthetic. Data derived from real records can retain re-identifiable structure — rare combinations of attributes are identifying even without names — so "generated from production" is not the same as "not personal data".
- How much data should a test fixture contain?
- Enough to expose pagination, sorting and N+1 queries, which usually means more than the handful a fixture starts with. Bugs that only appear past the first page are invisible in a ten-row dataset.
Common errors and gotchas
- Assuming generated names and addresses are fictional. Some will coincide with real people and places.
- Using generated email addresses in a test that actually sends mail.
- Generating data that is too clean, so the code never meets the messy input production has.
- Producing a dataset without edge cases — very long names, missing fields, non-Latin scripts.
- Letting generated data leak into production through a seed script that runs in the wrong environment.