Fake Data Generator — Seeded Test Records, CSV or JSON

What this tool does

It generates rows of placeholder records — the fake-but-plausible data you need to fill a table, a fixture or a screenshot before the real thing exists. You choose the columns your schema has, set how many rows, and get a dataset you can copy as CSV or JSON. Every value is invented from small fixed word lists, so it reads like real data without belonging to anyone.

Seeded and repeatable

The generator is deterministic: a given seed and column list always yields the same rows. That is the feature that makes fake data useful in development — you can commit the seed alongside a test, or paste it into a bug report, and get the exact dataset back. Bump the seed for a fresh set; the shape stays identical.

Common columns

Column	Example
Full name	Grace Hopper
Email	grace.hopper@example.com
UUID v4	4f9a…-…-…-…-…c1
Date	2014-07-23
Integer / decimal	1748 / 542.19

Emails use the reserved example.com domain so they can never reach a real inbox.

Use it as a fixture, not as data

Fake rows are for the places real data does not yet exist — a development database, a demo, a layout test. They are not a way to anonymise real data: swapping a name but keeping the structure can still leave someone identifiable. Generate into a test environment, and leave production records alone.

Columns within a row belong together

A row is generated as one record, not as a set of independent columns. The name, the first and last name fields, and the email address in the same row describe the same invented person: if the name column says Radia Berners-Lee, the email column says radia.bernerslee@example.com, not an address belonging to someone else. Earlier versions drew each column separately, which produced rows where a username and a display name disagreed — exactly the kind of inconsistency that makes fake data useless for testing a profile page or an email template.

Fields that are not identity — a city, a date, a number — are still drawn independently within the row, so two rows can share a city. That is realistic and does not break anything: nothing in the data claims a city belongs to a person.

Why the seed matters more than the data

The generator uses a seeded pseudorandom number generator, not Math.random. That distinction is the whole reason this is useful for testing. With an unseeded source, a test that fails on a name containing an apostrophe fails once and then passes on the next run, because the input changed. With a seed, the same seed and the same column list produce the same rows every time, on your machine and on a colleague's, so a failure is reproducible and the offending row can be kept as a regression case.

It also means the seed is a thing worth committing. Put it in the test setup, or in the bug report, rather than photographing the output — a seed plus a column list is a complete description of the dataset in a few characters. Changing the seed changes every value at once; the shape of the data and the set of columns stay identical, which is what makes it a safe way to get a second dataset.

Two caveats follow from the seeding. First, the values are deterministic, not random in a cryptographic sense: anyone with the seed can regenerate the rows, so never treat generated values as secret. Second, because the word lists are small, a large row count repeats values — 1,000 rows will contain duplicate names. That is fine for layout and volume testing and misleading if you were expecting 1,000 unique entities.

Loading it into a database

The CSV output follows RFC 4180: a value containing a comma, a double quote or a newline is wrapped in quotes, and inner quotes are doubled. That is what makes the file importable without a custom parser — psql \copy, MySQL LOAD DATA, SQLite .import, pandas' read_csv and a spreadsheet's import dialog all handle it. Two practical notes: the file has a header row and no trailing newline, and dates are written as ISO YYYY-MM-DD, which every one of those importers reads unambiguously, unlike 03/04/2026.

For a schema where column names differ from the labels here, generate to CSV and rename the header line, rather than editing each row. And if a target column is a foreign key, fake data alone will not satisfy it — the values have to come from the parent table, which is a job for a fixture factory, not a generator.

What the emails and addresses can and cannot reach

Addresses are built on the reserved example.com domain, which RFC 2606 sets aside so that documentation and test data can never deliver to a real inbox. That is a deliberate safety property: a test that sends a welcome email will not reach a stranger. It also means the addresses will be rejected by any validation that requires a real, resolvable domain, so do not use them to test the success path of an email-verification flow.

Street addresses and company names are assembled from fixed word lists, not from real postal data. They look plausible and are not valid addresses — no postcode matches the city, and no company exists. If a test needs a genuine postal format, generate the structure here and validate it against a real address database separately.

Frequently asked questions

Go deeper

Longer explanations of the problems this tool solves:

SQL formatting and test data: preparing a database

Sources

• RFC 4122 — UUID (the v4 form this generator produces).
• RFC 2606 — the reserved example.com domain used for fake emails.