Generate synthetic records with the fields you choose, exported as CSV, JSON or SQL inserts. Email addresses use the domains RFC 2606 reserves for examples, so no generated address can reach a real mailbox, and every record is labelled synthetic.
Settings
Recent results
Generated locally in your browser β your settings and results never leave this page.
Why fixtures need to be synthetic
The convenient way to fill a development database is to copy production. It is also the way organisations end up with real customer records on laptops, in screenshots, in error reports and in analytics from staging environments. Once real data has been copied it is very hard to know where all the copies are.
Synthetic data removes the problem at the source. Nothing here describes a real person, so a fixture that leaks is an inconvenience rather than an incident. The trade-off is that generated data is less messy than the real thing, and that difference is worth understanding rather than ignoring.
Reserved domains are not decoration
The email addresses use example.com and its siblings because RFC 2606 reserves them for exactly this purpose. They resolve nowhere and accept no mail.
The failure this prevents is specific and common: a staging environment configured to send real email, seeded with plausible-looking addresses at real domains, mailing strangers. Every reserved-domain address in a fixture is one that cannot participate in that. It is the same reasoning behind reserved IP ranges, and it costs nothing to observe.
What generated data will not tell you
The names in this tool are short, ASCII, and free of punctuation. Real names are not. They contain accents and non-Latin scripts, apostrophes and hyphens, and vary enormously in length. Some people have one name; some have several. Assumptions about a first name and a last name are wrong for a substantial part of the world.
A layout tested only against names like these will look fine and break on contact with real users. If you are testing text handling seriously, deliberately include long values, right-to-left scripts, combining characters and emoji β the Unicode generator alongside this one is useful for exactly that.
The same applies to distributions. Ages here are uniform between 18 and 80; real populations are not. Scores are uniform; real metrics cluster. If you are testing anything that depends on the shape of the data β a chart, an aggregate, a percentile β generate to that shape rather than assuming uniform values will behave like real ones.
Three exports, three jobs
CSV is for spreadsheets and bulk import tools. Values that begin with a character a spreadsheet would treat as a formula are prefixed with an apostrophe so they are read as text β a small precaution that prevents a generated value being executed when the file is opened.
JSON is for seeding through an API or loading in a script, and preserves types: numbers stay numbers and booleans stay booleans, which CSV cannot express.
SQL inserts are for loading straight into a database. The table name is stripped to a safe character set and string values have their quotes doubled. As with any generated SQL, read it before running it somewhere that matters.
Reproducible fixtures
Switching to seeded mode makes the output deterministic: the same seed and settings produce the same records every time. That is valuable for a test suite, where a failure you cannot reproduce is a failure you cannot fix. Recording the seed alongside the test lets anyone regenerate the exact dataset that broke.
Privacy
Records are generated in your browser and never transmitted, stored or logged. No real personal data is involved at any point.
Volume changes what you find
Ten records prove that a page renders. They prove very little else. Pagination bugs appear at the boundary between one page and two, so a fixture of exactly the page size is worth generating deliberately. Sorting bugs hide until there are enough rows for the order to be visibly wrong. Performance problems in a list view are invisible until the list is long enough to matter.
Generating a few hundred records costs nothing and exercises all of that. It is also the quickest way to discover that a layout which looks fine with short values breaks when a name runs to the edge of its column.
Keeping fixtures honest over time
Test data tends to drift away from the shape of production data. Fields get added to the real schema and not to the fixture; constraints tighten in production and the fixture keeps passing. The result is a test suite that is green and no longer tells you anything about whether the system works.
Regenerating fixtures when the schema changes, rather than patching them by hand, keeps them aligned. Recording the seed alongside a generated dataset means a failing test can be reproduced exactly, which is the difference between a bug you can fix and one you can only observe.
How to use the Random Test Data Generator
- Set how many records you need.
- Edit the field list to keep only the columns you want.
- Set a table name if you plan to use the SQL export.
- Generate, then export as CSV, JSON or SQL insert statements.
Frequently asked questions
Is this data real?
No. Every record is synthetic. Names are assembled from fixed word lists, and email addresses use the domains RFC 2606 reserves for examples, so no generated address can reach a real mailbox. Nothing here corresponds to a real person.
Which fields are available?
id, first_name, last_name, email, age, city, signed_up, active and score. Type the ones you want as a comma-separated list; anything unrecognised is ignored and reported in a warning rather than silently dropped.
Why do the email domains all look like examples?
Because they are. RFC 2606 reserves example.com, example.org, example.net and the .test and .example top-level domains precisely so generated addresses cannot reach a real inbox. Using a plausible-looking real domain in test data risks sending mail to strangers when a fixture escapes into an environment that actually delivers.
Can I use this data in a production database?
For seeding a development or staging environment, yes. Never mix it into production data, because synthetic records that look real are difficult to identify and remove later. Keeping test data in test environments avoids a class of problem that is tedious to unpick.
Is the SQL export safe to run?
The table name is stripped to letters, digits and underscores, and string values have their quotes escaped, so the generated statements are well-formed. Review any generated SQL before running it against a database you care about β that is good practice regardless of source.
Does this data cover awkward cases?
Only partly. The names are simple ASCII, which is deliberately unrepresentative: real user data contains accents, non-Latin scripts, apostrophes in surnames, and names far longer than the ones here. Use the random Unicode character generator alongside this to build fixtures that test text handling properly.
How many records can I generate at once?
Up to 500 per batch, which is enough to populate a development database or exercise a paginated list. For very large datasets, generating in the target system is more practical than moving them through a browser.
Generate test data for a fixture
A realistic JSON fixture you can drop into tests.
- Random Test Data Generator you are hereGenerate records with realistic-looking field values.
- Random JSON Data GeneratorShape those records into the JSON structure you need.
- JSON FormatterFormat the fixture before committing it.
- JSON ValidatorConfirm it parses before a test suite finds out for you.
