A row is not a line
Splitting a CSV by counting newlines is the mistake that produces two broken files out of one working one. The CSV format allows a line break inside a quoted field, and it is common in real data: a mailing address with the street on one line and the city on the next, a comment box, a product description pasted out of a document. Cut between those two lines and the first piece ends with an unterminated quote while the second starts mid-sentence, and neither one parses.
This tool parses the whole paste into rows first and only then counts, so a record spanning three physical lines is one row and is never cut in half. When it finds embedded line breaks it tells you how many, because that is also the reason your editor and your database disagree about how many records the file contains.
Choosing the chunk size
The number that matters is whatever your destination enforces, and importers state it in rows rather than bytes far more often than not. Where the limit is a file size instead, work backwards: divide the byte size of the original by the number of rows to get an average row width, then divide the limit by that and take off a comfortable margin, because rows are not uniform and the header is repeated on every chunk. Anything with variable-length text fields deserves a bigger margin than you think.
| Rows | Chunk size | Chunks | Last chunk |
|---|---|---|---|
| 10,000 | 1,000 | 10 | 1,000 |
| 10,001 | 1,000 | 11 | 1 |
| 999 | 1,000 | 1 | 999 |
| 2,500 | 1,000 | 3 | 500 |
The second row is the one to plan for. One row over a round number produces a chunk of one, which is harmless for an import and looks alarming in a folder listing.
Why the header goes on every chunk
An importer reading chunk 4 in isolation has no idea what the columns are unless the header is there. Repeat it and each piece is a valid, self-describing file that can be loaded in any order, retried on its own, or handed to a colleague without instructions. The cost is one duplicated line per chunk, which is nothing.
Turn the repetition off only when the destination is a tool that concatenates the pieces back together before parsing, in which case repeated headers would appear as data rows in the middle of the table. That is the narrower case of the two, so the switch defaults to on.
Line endings and what the output preserves
Field content is preserved exactly and re-quoted only where the format requires it: a field containing the delimiter, a quotation mark, a line break or leading or trailing whitespace gets quotes, everything else does not. Leading zeros in a postcode and long numeric identifiers stay as text, because nothing here converts anything.
The line-ending choice applies between rows and defaults to LF, which every current tool accepts. CRLF is what the original specification asks for and what a handful of older Windows importers still insist on; it costs one extra byte per row and is invisible everywhere else. If the destination has ever complained about a stray carriage return, or about rows running together, that switch is the first thing to try. To go the other way and repair a file whose quoting or delimiter is already wrong, start at the delimiter and quoting fixer instead, and to check the pieces before you send them, the table cleaner flags ragged rows.
Questions people ask
Does splitting change any values?
No. Rows are re-emitted from the parsed cells with quoting applied only where the format requires it, so content is byte-for-byte what you pasted apart from the quoting itself and the line endings you chose. Leading zeros survive, long identifiers survive, and dates are never reinterpreted. Short rows are padded out to the full column width so each chunk is square.
Can I get all the chunks in one go?
Each chunk has its own copy button, and the display count controls how many are drawn. There is no download of separate files, because that would mean either a zip or a stream of browser downloads and a static page is a poor place for either. For more than a few dozen chunks, a two-line script on your own machine is the better tool and will not make you click.
What happens to the header if there is not one?
Set the first line to "is data" and every line is treated as a record. The columns are then called col1, col2 and so on internally, the header repetition option has nothing to repeat and is ignored, and each chunk is a plain slice of rows. This is the right setting for an extract that was produced headerless on purpose.
Why does the row count differ from what my text editor shows?
Almost always because some fields contain line breaks. The editor counts physical lines; this counts parsed records, and a record with a two-line address occupies two lines and one row. The warning above the results tells you how many embedded breaks were found. If that count is zero and the numbers still differ, check whether the file ends with a trailing newline — that empty final line is not a row and is not counted here.