Design a schema, pick a row count, download realistic fake rows as CSV, JSON, NDJSON, SQL or Excel. Up to 100,000 rows, linked tables with real foreign keys, and the same seed always gives you the same file. Free, no daily cap, nothing uploaded.
Or ignore these and build your own schema below.
Name each column, choose what it holds, and set how often it should be blank.
Every row here gets a foreign key drawn at random from the first table, so joins actually work.
The first few rows, refreshed as you edit.
Tick more than one and you get a ZIP.
Almost every fake data site works the same way: a generous looking builder, then a cap. A thousand rows a day, or a paywall the moment you want a second table or a repeatable file. That cap is the whole product. This page has no cap, no account and no daily counter, because it runs entirely in your browser. Your schema, your column names and the finished file never touch a server. The page counts an anonymous visit and, when a run finishes, the number of rows it produced. Nothing else is sent, and no file is ever uploaded.
The seed is the part most free generators skip. Type a word into the seed box and the same schema will produce exactly the same rows tomorrow, on another machine, for a colleague. That turns a random dataset into a fixture: a failing test can be handed over with nothing more than a seed and a schema, and the person picking it up gets the identical file. Change the seed and you get a completely different set with the same shape.
Seed data with one flat table only gets you so far. Tick the second table and every child row is given a key sampled from the parent table's real values, so a join returns rows instead of nothing. The SQL export writes the parent first and batches the inserts so a large file still loads. It adds the FOREIGN KEY constraint when the column you point at is the primary key or is ticked Unique, and leaves it out with a note when it is not, because a key pointing at an unconstrained column stops the whole script loading.
CSV is the safe default and the one format that comfortably handles the full hundred thousand rows. JSON and NDJSON suit API fixtures and log pipelines. SQL gives you a script you can pipe straight into a scratch database. Excel is the one real limit here: the spreadsheet writer builds the entire workbook in memory before it can save anything, so it is capped at 25,000 rows in total across both tables rather than letting it freeze your tab. Excel opens a CSV perfectly well above that.
Names, companies, addresses and card numbers are invented by a random generator. They look plausible, and that is the point, but they are not sampled from real people and any resemblance to a real person, business or account is coincidence. Card numbers pass the Luhn checksum so validation code accepts them. They are random digits behind a real network prefix, not reserved test numbers, so treat them as fake data only and never type one into a live payment form. Use all of it for testing, demos and screenshots, never as a stand in for real records.