Sample CSV files

Four starting points

The generator ships with schema templates that cover the shapes people usually want a sample file for. Open the generator, pick one, set the row count, download:

• Users — id, name, email, city, signup date. The default import test.
• Orders — order id, customer, product, quantity, price, status, date. Numeric and categorical columns together.
• Employees — name, job title, department, hire date, salary. See employee sample data for the full breakdown.
• Sensors — device id, timestamp, reading. A time series, useful with sequential dates.

Every template is a starting point rather than a fixed file — add, remove and rename columns before exporting.

What a small sample looks like

id,first_name,last_name,email,city,country,signup_date,is_active
1,Elena,Rossi,elena.rossi7@example.org,Lyon,France,2024-03-18,true
2,Marco,Schneider,marco_schneider@example.com,Hamburg,Germany,2024-07-02,true
3,Aisha,Yılmaz,aisha.yilmaz@example.net,Izmir,Türkiye,2025-01-27,false
4,Priya,Nair,priya.nair42@example.org,Osaka,Japan,2025-04-11,true

Note the third row: a non-ASCII city and surname in a UTF-8 file. That single row finds more import bugs than the other three combined, which is why it is worth keeping a sample file honest rather than tidy.

Choosing a row count

Sample size should follow what you are testing, and the common mistake is picking a round number that tests nothing:

• 10–100 rows — reading the file by eye, checking column mapping, writing a parser test.
• 1,000–5,000 rows — pivot tables, charts, anything where distribution matters.
• 50,000–100,000 rows — import performance, pagination, memory behaviour, and finding the point where your UI stops being usable.

100,000 rows is the per-export ceiling. For more, export several times with different seeds and concatenate, stripping the header from every file after the first.

Making the sample awkward on purpose

A sample file that imports cleanly proves very little. The controls that make a file useful as a test:

• Blank % on optional columns produces empty cells, so you find out whether your importer distinguishes empty string from null.
• Text fields — a Sentence or Words column will eventually contain a comma, which forces quoting and exercises your parser properly.
• Leading zeros — a Pattern field like 0##### is the fastest way to prove whether your pipeline treats identifiers as numbers.
• Header row off — for testing an importer that expects positional columns.

Quoting follows RFC 4180: fields containing a comma, quote or newline are quoted, and embedded quotes are doubled. The CSV format page shows the anatomy.

Same file every time

Enter a seed and the download is byte-identical on every machine and every run. That is what makes a generated sample suitable for committing next to a test: the assertion can name a value in row 3 without the file drifting underneath it. Change the seed and you get a different file of the same shape, which is a good way to check a parser test passes for the right reason.

Other formats from the same schema

Nothing about the schema is CSV-specific. The same columns export as TSV when your data contains commas and tabs are cleaner, JSON for a frontend fixture, NDJSON for streaming tools, SQL for a seed script, or XML for an integration test.

Common questions

Related

• Sample JSON data — the same schemas as typed JSON.
• Excel sample data — importing without Excel mangling your columns.
• Employee sample data and sales sample data.
• CSV format reference — quoting, delimiters and compatibility.