Fake Test Data Generator
Generate mock user data and export JSON or CSV
Fake Test Data Generator tool
Fake Test Data Generator: key facts
- What it does
- Generate mock user data and export JSON or CSV
- Category
- Generators
- Cost
- Free, with no account, sign-up, or install.
- Your data
- Runs entirely in your browser — the files and text you enter are never uploaded to a server.
- Last reviewed
- . Report an incorrect result.
What the Fake Test Data Generator does
Building a UI, seeding a database, or testing a CSV importer all need realistic-looking data — and typing it by hand is tedious. This generator fabricates mock user records on demand, so you can populate a table or an API fixture in one click.
Tick the fields you want — full name, email, phone, address, UUID, and job title — and set how many rows to create, from 1 to 100. Names are assembled from built-in first/last name lists, emails are derived from those names against dummy domains, addresses combine real-sounding street and city components, and UUIDs come from the browser's Web Crypto randomUUID for proper v4 format. The results land in a clean table you can export to JSON or CSV, or copy as JSON.
Front-end developers filling out a prototype, QA engineers stress-testing a form, and anyone who needs sample rows for a demo use it to skip the busywork. Because every value is invented locally, there is no risk of leaking real personal data into a test environment.
Using the Fake Test Data Generator, step by step
- Check the fields you need; at least one must stay selected.
- Enter how many rows to generate, from 1 to 100.
- Click "Generate" to build the table — click again any time to reroll a fresh set.
- Review the data in the table.
- Export with "Export JSON" or "Export CSV", or use "Copy JSON" to grab it for code.
Plausible data, generated locally
The generator produces synthetic records — names, addresses, emails, phone numbers and similar fields — that look realistic without corresponding to anybody. Generation happens in your browser, so nothing is fetched and nothing is sent.
The point of realistic-looking data is that it exercises a system the way real data will. Fields filled with placeholder strings hide the problems that matter: names with apostrophes and hyphens, addresses that do not fit a fixed number of lines, unusually long values that break a layout, and characters outside ASCII.
That makes it useful for seeding a development database, populating a design mockup, load testing, and writing test fixtures.
- Generated emails and phone numbers are formatted plausibly but are not real contact details.
- Names include the punctuation and length variation that breaks naive validation.
- Records are independent, so no relationships between them are implied.
What makes this one worth using
- All data is fabricated in your browser from built-in lists and the Web Crypto API — nothing is fetched and nothing is uploaded, so test data never touches a server.
- UUIDs use crypto.randomUUID, producing standards-compliant version-4 identifiers rather than weak pseudo-random strings.
- One click gives you both JSON (an array of objects) and CSV (with properly quoted values), matching how you would seed an app or a spreadsheet.
- Field selection and a 1–100 row count let you generate exactly the shape you need, from a single example to a full table.
Why synthetic data is the responsible choice
Using real personal data in development, testing, or demos is a genuine compliance problem. Under the GDPR and comparable regimes, personal data must be processed for a stated purpose with a lawful basis, and copying a production database into a staging environment satisfies neither — while multiplying the number of places a breach can happen. Synthetic data removes the question entirely.
Naive anonymisation is not a substitute. Stripping names from a dataset frequently leaves it re-identifiable through combinations of remaining fields, and this has been demonstrated repeatedly on supposedly anonymised medical and location datasets. Generating fresh data is more robust than attempting to launder real data.
Two limitations worth knowing. Generated records are independent, so they carry none of the correlations real data has — a postcode will not match its city, and ages will not correlate with anything. Where those relationships matter for testing, they have to be constructed deliberately. And plausible-looking values are not valid ones: generated card numbers, national identifiers, and phone numbers will fail real checksum and format validation, which is usually what you want, but means they cannot be used to test an integration end to end.
Frequently Asked Questions
Is this data safe to use in tests?
Yes — every value is randomly assembled from generic placeholder lists and dummy domains, so it represents no real person. Using fabricated data like this is the recommended way to avoid exposing real personal information in development and test environments.
Are the email addresses real?
No. Emails are built from the generated names against placeholder domains such as example.com, which are reserved for documentation and testing. They are syntactically valid but will not deliver mail, which is exactly what you want for fixtures.
What is the difference between the JSON and CSV exports?
JSON exports an array of objects keyed by field name, ideal for seeding an API, a database, or a JavaScript fixture. CSV exports a header row plus comma-separated, quoted rows, ready to open in a spreadsheet or feed an import routine.
Why cap the output at 100 rows?
The tool is built for quick fixtures and demos rather than bulk dataset generation, so the row count is clamped between 1 and 100 to keep the table responsive. Generate repeatedly and concatenate the exports if you need more.
