Build a schema, pick your field types, and generate up to 1,000 rows of realistic test data. Export instantly as JSON, CSV, or SQL INSERT statements.
First name, last name, full name, username, gender, age, date of birth, avatar URL.
Email address, phone number, street address, city, country, ZIP/postal code.
UUID v4, auto-increment integer, boolean, random integer range, random float, hex color.
Past date, future date, ISO timestamp, Lorem ipsum sentence, company name, domain, URL, IP address.
Test data built from neat placeholders hides the failures that matter. Every field filled with "Test User" and "123 Main Street" exercises one narrow shape, and the bugs waiting in production are all in the shapes you did not try.
Names are the clearest case. A test suite using only Anglophone names never encounters apostrophes as in O'Brien, hyphens, accented characters, names shorter than three letters, names longer than a database column allows, mononyms with no surname at all, or scripts that render right to left. Each of these has broken real systems, and several have broken them in ways that reached the news.
The same applies elsewhere. Addresses without a postcode, or with a postcode that is not five digits. Phone numbers with country codes of varying length. Email addresses with plus-addressing or a long top-level domain. Dates in February, on the 29th, or spanning a daylight saving transition. Generating varied data makes these routine rather than exotic.
Randomly generated test data has a serious drawback: a test that fails once and passes on re-run tells you almost nothing, and you cannot reproduce the failure to fix it. This produces flaky suites that teams learn to ignore, which is worse than having no test.
The solution is seeding. A pseudo-random generator initialised with a fixed seed produces the same sequence every time, so data is varied across fields but identical across runs. When a failure occurs, log the seed — then that exact dataset can be regenerated on demand.
Property-based testing takes the idea further: generate many random cases, and when one fails, automatically shrink it to the smallest input that still fails. That combination — broad exploration plus a minimal reproducible case — finds edge cases that hand-written tests miss, and reports them in a form that is actually debuggable.
The tempting shortcut is copying a production database into a development environment, and it is a serious mistake. Development and staging systems have weaker access controls, are backed up less carefully, are accessible to more people, and end up on laptops. A copy of real customer data in those environments is a breach waiting to be discovered.
It is also a compliance problem. Under GDPR, personal data may only be processed for the purpose it was collected, and "testing our software" is not that purpose. Similar constraints apply under HIPAA for health data and PCI DSS for payment data, and regulators have fined organisations for exactly this.
If production-like data is genuinely needed for volume or distribution testing, anonymise it properly — which means more than removing names. Quasi-identifiers such as a postcode, a birth date and a gender in combination re-identify most individuals, so real anonymisation requires generalisation or synthesis rather than deletion of the obvious fields. Generated data avoids the question entirely, which is usually the better answer.
No. All data is generated entirely in your browser using JavaScript. Nothing is sent to a server — the generator runs offline once the page loads.
Yes. Add one field per column, choose the matching type, set the row count, and export as SQL INSERT statements. Paste directly into your database client.
1,000 rows per generation. For larger datasets, generate multiple batches and combine the output files.
Yes. Each field row has a remove button. You can also rename fields at any time — the output key names update live when you generate.
So failures are reproducible. Unseeded random data produces tests that fail once and pass on re-run, which teams learn to ignore. Log the seed and you can regenerate the exact failing dataset.
You should not. Non-production environments have weaker controls and wider access, and under GDPR and similar regimes testing is not the purpose the data was collected for. Removing names is not anonymisation — combinations of postcode, birth date and gender re-identify most people.