The seed is the part worth caring about
Most sample data is thrown away a minute after someone looks at it. The moment a test fails, that becomes a problem: the file that triggered the failure is gone, and the next click produces different rows.
A seed fixes that. Every value on this page comes out of a small deterministic generator started from the text in the seed box. Type toolexe, keep the same columns, and row 47 holds the same email address today, tomorrow, and on a colleague's machine. Write the seed into your test file next to the expected output and the whole scenario replays on demand.
Change one character of the seed and the entire table changes. That is the point. When you need a fresh sample, press New. When you need yesterday's sample, type yesterday's seed.
Building a file, start to finish
- Pick a starting shape from the row of presets. Each one loads a column set and a row count that match a real table, so you rarely start from an empty list.
- Rename the columns to match your schema. Header text goes into the file exactly as typed, so
user_idandUser IDboth work, and your parser sees whichever one you wrote. - Set the type per column. Numeric types show a minimum and maximum pair, which keeps salaries out of the single digits and quantities out of the thousands.
- Set the row count and the seed. Small counts read better while you are still shaping the columns. Raise the count once the header line looks right.
- Switch on the rough edges the importer should survive. The table view highlights every damaged cell in place, so you see what the parser will hit.
- Copy for a quick paste into a sheet, or download the file when a script or an upload form needs to read it.
Column types and what each one tests
Types were chosen for the failure they provoke, not for variety. A generator that only produces neat names and round numbers proves very little.
| Type | Sample value | What it exercises |
|---|---|---|
| Row ID | 1000, 1001, 1002 | Sequential keys, so a duplicate import is obvious at a glance |
| UUID v4 | 9f2c1ab4-3d7e-4a01-b2f0-5c8d61e4a7bb | 36 character keys, wide enough to expose column truncation |
| priya.nair@toolexe.com | Uniqueness checks and address validation rules | |
| Timestamp | 2025-11-04T09:16:23Z | ISO 8601 parsing and time zone handling |
| Date | 2026-02-19 | Date columns that arrive as text and stay text |
| Price | 128.40 | Two decimal places, including values ending in zero |
| Integer range | 42 | Bounds you set, useful for quantity and count fields |
| Decimal range | 0.8134 | Four decimal places, for rates and scores |
| Boolean | true, false | Whether your loader reads text booleans or expects 0 and 1 |
| IPv4 | 198.51.44.7 | Log tables and address parsing |
| SKU code | SKU-KTP-084 | Mixed letters and digits that break naive numeric casts |
| Always empty | A column that is blank in every row, which some parsers drop entirely |
Names come from a mixed pool across several regions rather than a list of English placeholders. Sample data full of identical filler names hides sorting and collation bugs that show up the first week after launch.
Rough edges, and the bug each one finds
Clean data passes every test. Real exports arrive from spreadsheets, from support agents pasting into a form, and from systems built before anyone agreed on a format. Each toggle reproduces one defect that reaches production files often.
Tab inside a value
The defect TSV has no answer for. Unlike CSV, there is no quoting rule in common use, so a tab pasted into a note field silently adds a column to that row. Your parser reports the wrong field count, or worse, reports nothing and shifts the data.
Empty cells
Two tabs in a row. Whether that means an empty string, a null, or a zero is a decision your loader makes, and most loaders make it inconsistently across column types.
Leading zeros
A code like 004821 survives the file and dies in the spreadsheet, where it becomes 4821. Any round trip through Excel needs this case in the fixture.
Accents and non-Latin text
Names such as Ayşe Yıldız and Nguyễn Hà break byte-length assumptions, sort in surprising orders, and turn into question marks the moment a connection defaults to Latin-1.
Padding spaces
Two invisible spaces on a key. The row looks correct in every view and fails every join. Trimming on import is the fix, and this toggle proves whether you do.
Ragged rows
A row with one field too few or too many. Importers align by position, so one missing tab pushes every later value one column left for the rest of that row.
The bad row meter counts the rows carrying a stray tab or a wrong field count. Treat that number as your target: an importer that rejects those rows with a line number is doing its job, and one that swallows them without a word is the reason this page exists.
Loading the file where it needs to go
Tabs are the reason TSV survives in data work. No quoting, no escaping arguments, one character between fields. Every database has a fast path for it:
psql -c "\copy accounts FROM 'sample-toolexe.tsv' WITH (FORMAT text, HEADER true)" mysql -e "LOAD DATA LOCAL INFILE 'sample-toolexe.tsv' INTO TABLE accounts FIELDS TERMINATED BY '\t' IGNORE 1 LINES" sqlite3 app.db ".mode tabs" ".import --skip 1 sample-toolexe.tsv accounts"
For a spreadsheet, copy is faster than download. Excel and Google Sheets both split pasted text on tabs with no import dialog at all. A saved file is different: Excel reads a .tsv file as the system code page unless the bytes start with a UTF-8 marker, so accented names arrive mangled. Tick the BOM box before downloading when the file is headed for Excel, and leave it off for anything else, since a stray marker on the first header cell breaks string comparisons in scripts.
Generated rows are not a substitute for a sample of the real thing. Production data carries duplicate keys, values nobody documented, and formats that predate the current schema. Use this page for the shapes you already understand and for the defects you want to prove against. Also worth stating plainly: never copy live customer records into a shared test fixture. Generated rows exist so nobody has a reason to.
Where this page stops
- Rows top out at 5,000. Generation and preview both run in this browser tab, and larger fixtures belong in a script that streams to disk.
- The table view renders the first 200 rows. The raw view and the download hold the full set.
- Columns are independent. A city and a country in the same row will not agree, and a total will not match its price and quantity. Relationships across columns need a script.
- Values repeat. The pools hold a few dozen entries per type, so a thousand rows means plenty of duplicate names. Row ID and UUID are the two types that stay unique.
- No referential integrity, no foreign keys, no distribution control. Every value is drawn evenly, which is nothing like the long tail real data has.
- Nothing leaves the page. Generation, preview, and the download are all local, so no seed and no file reaches a server.
Nearby pages
Commas instead of tabs, with quoting handled, comes from the random CSV generator. Once you have a table, TSV to JSON turns the rows into records for an API fixture, TSV to CSV quotes the values that need it, and TSV to Base64 packs the file into a string for a config value or a test payload.
