Fake Data
Names, emails, addresses and phone numbers
Development against realistic data surfaces problems that a table full of "test test" never will: names with apostrophes and accents, addresses that run to four lines, phone numbers in formats your regular expression did not anticipate. Generating plausible records is the cheapest way to find those before a real user does.
The other reason to generate rather than copy is legal. Using a slice of production data in a development database means personal data has left its intended system, which is exactly what data protection rules exist to prevent. Synthetic records give you the shape of real data with none of the obligation attached, and everything here is produced in your browser.
How to use it
- Pick the fields you needNames, email addresses, postal addresses and phone numbers can be generated together so a row stays internally coherent rather than assembled from unrelated fragments.
- Choose how many rowsA handful for eyeballing a UI, a few thousand for testing pagination, sorting and the point at which your table component starts to struggle.
- Copy it into your seed scriptTake the output straight into a fixtures file or a seeding migration so the same data can be regenerated by anyone on the team.
Frequently asked questions
Are these real names, addresses or phone numbers?
No. Names are assembled from common given and family name lists, and addresses are constructed from plausible components rather than looked up. Any resemblance to a real person or a deliverable address is coincidence — which is the point, but also why you should never treat generated contact details as safe to actually contact.
Can I use production data in my development database instead?
You should not. Copying personal data into a less protected environment is one of the most common causes of avoidable breaches, and under GDPR and similar regimes it needs a lawful basis you probably do not have for development. If you must, pseudonymise properly — which usually turns out to be more work than generating fresh data.
Will the same data be generated each time?
No, each run produces new values. If you need stable fixtures — so a failing test is reproducible — generate once and commit the result rather than calling a generator at test time.
Does this test my validation properly?
Partly. Generated data is plausible, which means it mostly exercises the happy path. To test validation you also need deliberately awkward input: an empty string, a name that is a single character, an address with a newline in it, an email at the length limit. Realistic data and hostile data are different test sets.
What makes a good test email address?
Use a domain reserved for the purpose. example.com, example.net and example.org exist precisely so that documentation and test data cannot accidentally reach a real inbox, and RFC 2606 sets them aside for exactly this. Never invent a domain that might belong to someone.