Sample CSV Generator
Generate a genuine CSV or TSV in seconds — seven content types, real RFC 4180 quoting, independent delimiter and encoding control, and an exact target file size. No fake structure. Runs entirely in your browser.
| ID | Name | Category | Value |
Quick Tips for the Right Test File
Features
The Format With No Real Standard
Every other generator in this set produces a file with a genuine specification behind it — Sample XLSX follows Office Open XML down to the byte, and even Sample SVG's plain-text markup has a formal W3C grammar. CSV has RFC 4180, but RFC 4180 describes what CSV probably ought to look like, written years after the format was already in widespread, inconsistent use — it was never universally adopted, and plenty of real-world "CSV" files predate it or ignore it entirely. That's the entire reason this generator spends more of its interface on format mechanics (delimiter, line ending, encoding) than any other tool in this library: for CSV, those mechanics are the actual source of real-world bugs, not an afterthought around the content.
Quoting Is Where Parsers Actually Break
Splitting a line on commas is trivial. Splitting it correctly, when a field might legitimately contain a comma, a quote character, or an entire embedded line break, is not — and that gap is exactly where a surprising number of production CSV bugs live. Quoting Edge Cases generates real examples of each: a name containing a comma, a quoted phrase containing an embedded quote (correctly doubled per RFC 4180), and a field that spans two physical lines inside a single quoted value.
That last case is the one most naive implementations get wrong — a parser that treats every line break as a new row will split one logical record into two, silently corrupting the data without ever raising an error. A file built specifically to contain that case is a fast, direct way to find out whether a given parser handles it before production data does the finding instead.
The empty-quoted-field case matters for a quieter reason: it's the difference between "no value was provided" and "an empty string was explicitly provided," a distinction that genuinely matters to some downstream systems and is trivially easy for a hand-written writer to collapse into the same output either way.
Padding Without Anywhere to Hide It
Every binary or XML-based format in this library pads toward an exact size using a slot the format itself guarantees a decoder will skip — a JPEG comment marker, a PNG ancillary chunk, an XML comment. CSV has nothing equivalent. There's no reserved byte sequence, no comment syntax, no metadata block a parser is obligated to ignore. Rather than fabricate one, padding here is upfront about what it actually is: a plainly labeled trailing column, present but empty in every real data row, holding the actual padding characters in a single cell of the final row.
The upside of that honesty is real precision — a run of plain ASCII characters never needs RFC 4180 escaping, so the bytes added are always exactly the bytes requested, with none of the block-alignment or minimum-chunk-size caveats that show up elsewhere in this library. The trade-off, stated plainly rather than glossed over, is that a strict parser expecting every row to match the header's column count precisely could treat that trailing column as a genuine extra field — which it is, just an empty one everywhere except the very last row.
Text Pretending to Be Numbers, Dates and Nothing
CSV has exactly one data type: text. Every value in Sample XLSX is genuinely typed — a number is a number, a date is a date — but a CSV file has no such mechanism at all; the string "42" and the string "forty-two" are equally valid cell contents as far as the format itself is concerned. Ambiguous Numbers and Date Formats both exist to make that gap concrete: a zip code with a leading zero, a number too large for a JavaScript safe integer, a date written in a way that's genuinely ambiguous between US and EU conventions. None of these are edge cases dreamed up for the sake of it — they're the specific, ordinary things that quietly corrupt data the moment something downstream decides to guess at the type instead of being told.
Empty & Null pushes on the same nerve from the opposite direction — before a system can decide what a value means, it has to decide whether there's a value at all, and CSV offers no single agreed way to say "nothing here." A genuinely empty field, three space characters, and the literal text "NULL" are three different byte sequences that a lot of real-world data treats as interchangeable and a lot of real-world code does not.
Who Actually Needs a Real Test CSV
Backend developers building or hardening a CSV import feature need Quoting Edge Cases and Empty & Null specifically, since those two content types cover most of the actual failure modes a hand-rolled or under-tested parser runs into. Data engineers validating an ETL pipeline's type inference need Ambiguous Numbers and Date Formats to confirm the pipeline asks rather than assumes. Frontend developers building a CSV export or import UI need the delimiter and BOM controls specifically to test against what Excel-using customers will actually upload, not just a clean, idealized file nobody really produces.
Where This Tool Isn't the Right Pick
If the test needs real typed cells, formulas, or multiple sheets, CSV structurally can't provide any of that — Sample XLSX is the right generator when the format itself needs to carry that information rather than leave it to convention. And if you already have real CSV or JSON data and need it converted rather than a new sample generated, CSV to JSON and JSON to CSV handle that conversion directly.