Fake Data Generator — Mock Names, Emails, Addresses as CSV, JSON or SQL
Pick fields, set a row count and a seed, and get realistic test data you can reproduce exactly.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
Simplified layout on small screens — the full version is on desktop.
Generate realistic-looking test data for fixtures, demos, database seeding and UI mock-ups: names, emails, phone numbers, addresses, companies, job titles, dates, UUIDs, IPs, amounts and more. Choose the fields, the number of rows (up to 1,000) and export as a table, JSON, CSV or a ready-to-run SQL INSERT.
Give it a seed and the same rows come back every time — bug reports and test suites can reference "seed 42, row 17" and mean something.
How to use Fake Data Generator
- Tick the fields you need. Column names follow snake_case conventions (
first_name,job_title). - Set the row count and, for reproducible output, a seed word or number.
- Choose the format — preview as a table, or switch to JSON, CSV or SQL.
- Copy or download. Regenerate for a fresh random set (leave the seed blank).
Synthetic by design
Every value here is made up from small built-in lists: the names are common given and family names from around the world combined at random, emails live on the reserved example.com / example.org domains, phone numbers use the fictional 555 exchange, websites end in .example.com, and addresses are street names that exist in a thousand towns attached to random numbers. Nothing is scraped, nothing refers to a real person, and nothing you generate can accidentally reach a real inbox or phone.
Why seeds matter
Random test data that changes on every run is useless for a failing test — you cannot reproduce it. A seeded generator gives you both: fresh-looking data and determinism. Type any word as the seed; the same seed with the same fields and row count always produces the identical rows, in the same order. Change one field and everything shifts, which is expected — the values are drawn from one stream.
Output formats
- CSV — RFC 4180 quoting, one header row. Imports into Excel, Sheets, pandas and every database's bulk loader.
- JSON — an array of objects with proper types: numbers are numbers, booleans are booleans.
- SQL — a single multi-row
INSERT INTO people (…) VALUES …with correctly escaped strings; rename the table after pasting.
What this is not
Not a load-testing dataset (1,000 rows is the ceiling; generate several seeds for more), and not statistically faithful — ages, amounts and dates are uniform, not shaped like real populations. For anything where the distribution matters, sample your own anonymised production data instead. For a single unique identifier, the UUID generator is quicker; for filler prose, the lorem ipsum generator.
Frequently asked questions
Are these real people?
No. Names are common first and last names combined at random; emails use the reserved example.com/.org/.net domains that can never deliver; phones use the fictional 555 exchange; addresses are generic street names with random numbers. Any resemblance to a real person is coincidence, and nothing can reach anyone.
How do I get the same data again?
Type a seed — any word or number. The same seed with the same fields and row count reproduces the rows exactly, on any device. Leave the seed blank for a fresh random set each time.
Can I generate more than 1,000 rows?
Not in one go — the cap keeps the page responsive. Generate several batches with different seeds ("batch1", "batch2"…) and concatenate the CSVs; IDs restart at 1 in each, so drop that column or renumber.
Why is the data statistically unrealistic?
Values are drawn uniformly: every amount between 0 and 1000 is equally likely, every age between 18 and 80. Real populations aren't like that. For testing layouts and logic that is fine; for testing algorithms that depend on distributions, use anonymised real data.
Can I change the SQL table or column names?
The table is people and columns are snake_case (first_name, job_title); edit them in the output before running it. Column names are the same across CSV, JSON and SQL so a schema written for one works for the others.