In short: RowSlice's CSV validator reads a CSV file in your browser and reports what would break an import: rows with more or fewer columns than the header, quotes that are never closed, bytes that are not valid in the file's encoding, a byte order mark, duplicate IDs, and the values another program is likely to have changed on the way, such as leading zeros and 16-digit numbers. It reports; it does not rewrite the file. Nothing is uploaded, and the file is read a few megabytes at a time, so size is not what limits it.
How to Check a CSV File Before You Import It
- Choose or drag in the CSV file. It is not uploaded, so a multi-gigabyte file is ready in a second, and the first rows appear as a preview.
- If one column is supposed to be unique —
email,customer_id, an order number — choose it, and repeated values in that column are counted too. - Press Check File. Every check runs in a single pass over the file.
- Read the report: each problem comes with a count of what it affects — rows, values, cells or characters, depending on the check. Save the offending rows to a separate CSV if you want to look at them in a spreadsheet.
Then fix the problem where the file was made, not in the CSV. A row that came out wrong usually means a value in the source system contains a comma, a quote or a line break that the export did not escape, and hand-editing the CSV fixes today's file while next week's export arrives broken in the same place.
What the Check Looks For
Every check below runs on every file, in one pass, whatever its size, and the counts are exact because the whole file is read rather than a sample of it. One thing cuts that short: an unclosed quote the parser never recovers from. It stops where it gives up, the report names the data row it stopped at, and every count then describes the rows above that point only.
| Check | What it means | What to do about it |
|---|---|---|
| Parse error: an unclosed quote or a row that never ends | A double quote was opened and never closed, so the parser read on past the end of the row | Fix the stray quote — everything below it is affected |
| Rows with the wrong number of columns | The row holds more or fewer values than the header has names | Nearly always an unescaped delimiter or quote |
| Bytes that are not valid in the file's encoding | The file is not the encoding it is being read as, so accented letters and symbols will arrive damaged | Convert it to UTF-8 |
| A UTF-8 byte order mark | Three invisible bytes at the very start of the file. Excel wants them; many importers read them as part of the first column name | Convert to UTF-8 without a BOM if a program, not a person, reads the file |
| A delimiter that is not a comma | Values are separated by semicolons, tabs or pipes — valid CSV, and the wrong thing entirely if commas were expected | Change the delimiter, or set the importer to match |
| Mixed CRLF and LF line endings | Part of the file ends rows the Windows way and part the Unix way, which happens when files are joined or edited on two systems | Most parsers cope; one that splits on line feeds alone leaves a stray carriage return on the end of the last value in a row. Re-save with one style |
| Blank rows | Empty lines between records, often at the end of the file | Importers differ: some skip them, some read them as a record with every field empty and reject the file |
| Duplicate column names | Two columns in the header have the same name | Which one an importer maps to is anyone's guess. Rename one in the export |
| Empty column names | A header cell with nothing in it, usually a stray delimiter at the end of the header row | Name the column or drop it, so the mapping screen has something to show |
| Column names padded with spaces | The header reads email, not email | A field mapping looking for the exact name will not find it. Trim it in the export |
| NUL and other control characters | Bytes that have no business being in text, usually from a failed export or a file that is not really text | Databases commonly refuse a value containing a NUL byte. Export the file again |
| Duplicate values in the ID column you choose | Two rows claim the same key, so an import that updates by key will process both | Decide which row is right, or remove duplicates by that column |
| Exact duplicate rows | The same record appears more than once, character for character | Remove the repeats, keeping the first copy of each |
| Columns that are empty in every row | A column that carries no data at all in this file | Leave it out of the mapping, or out of the export |
| Empty cells | How many values in the whole file are blank | Compare it with the fields your importer requires. For the count per column, use the CSV analyzer |
| Values with leading zeros | ZIP codes, account numbers and product codes like 00742, which are still intact in the file | Keep them out of Excel between here and the import |
| Numbers of 16 digits or more | Card numbers, IMEIs and long order references. Excel keeps 15 significant digits and turns the rest into zeros | Check them against the source if the file has been through a spreadsheet |
| Mixed or unreadable dates | One column holds more than one date format, or values no date parser will accept | Settle on one format in the export. 2026-03-18 is read the same way everywhere |
| Values padded with spaces | A value with a space before or after it, which is different text to an importer and to any duplicate check | Trim it in the export, or ignore spaces when you remove duplicates |
Rows with the Wrong Number of Columns
This is the commonest hard failure, and the one importers report in the most confusing way: a row number, a field count, and nothing about why. The header defines how many columns each row should have. When a row has a different number, the parser cannot line the values up with the names, and whatever the importer does next — reject the row, reject the file, or shift every value one column to the left — is wrong.
Three causes account for nearly all of them, and each is a character that belongs inside a value turning up where the parser reads it as structure.
| What is in the file | How a parser reads it | Cause |
|---|---|---|
Smith, John,42 | Three values where the header has two | A comma inside a value that was never quoted |
"Smith, John",42 | Two values, correctly | The same value, quoted the way the CSV standard asks |
"5 pipe,42 | Everything after it, commas and line breaks included, as one value that never ends | A value that starts with a quote which is never closed |
| An address split over two lines, unquoted | Two rows, each with too few values | A line break inside a field that was not wrapped in quotes |
A fourth cause is harmless and reported all the same: a delimiter left at the end of every row, which gives every row one extra, empty column. The report tells you how many rows are affected, and saving those rows to their own file is usually enough to identify the culprit column: where a row has one value too many, look for the free-text field — a company name, an address, a note someone typed.
The fix belongs in the export. The system that wrote the file should be wrapping any value containing a comma, a quote or a line break in double quotes; most can, given the right export setting. If you have to work with the file you have, save the offending rows to their own CSV, correct them in a text editor, and keep the header line with them.
Broken Quotes, and Why One Bad Quote Ruins Everything After It
In CSV, a double quote is not decoration. It switches the parser between two states. Outside a quoted value, a comma separates fields and a line break ends the row; inside one, a comma and a line break are ordinary characters, and the value ends only when the closing quote arrives. A quote that is written inside a quoted value is doubled: "He said ""hi""" holds the text He said "hi".
So a single stray quote — a measurement in inches, a nickname typed as Robert "Bob" Smith, a quoted phrase in a free-text note — puts the parser inside a value it will not leave. Commas stop separating fields. Line breaks stop ending rows. Ten, or ten thousand, later rows are swallowed into one enormous value, and the error is reported wherever that finally falls apart, which can be a long way below the row that caused it.
That is the single most useful thing to know when an importer names a row that looks fine: look above it. The check reports the data row number where the parse failed; the stray quote is at or above it, in the last row that still had the right number of columns. Nothing below that row was read, because the parser could not carry on past it.
Encoding, BOM and Delimiter Problems
A CSV file is plain text and carries nothing that says which character encoding it uses, so every program that opens one is guessing. When the guess is wrong you get Café for Café, or M�nchen for München, and an importer that rejects the row for an invalid character. The check reports bytes that are not valid in the encoding it detects, so you find out before the names in your customer list arrive mangled.
A byte order mark is the same story in reverse. Those three invisible bytes at the start of a UTF-8 file are what Excel on Windows needs before it will show accented letters correctly — and what many import scripts read as part of the first column name, so a column called id can no longer be found under that name. The check reports whether the file has one. Which way you want it depends entirely on what opens the file next.
All three are fixed in one pass by the CSV to UTF-8 converter, which also switches the delimiter between comma, semicolon, tab and pipe. If you want to know which encoding a file actually is before you convert it, UTF-8, UTF-16 and Windows-1252: which one is your CSV? works through the symptoms.
Duplicate IDs and Duplicate Rows
Two different problems hide under the word duplicate. Exact duplicate rows, where every value matches, usually mean an export was run twice or two files with overlapping date ranges were merged. Duplicate IDs are worse: the rows differ, but both claim the same key, so an import that updates records by key applies both and leaves you with whichever landed last. Which of them was right is a question the file cannot answer.
Choose the column that should be unique before the check runs, and repeated values in it are counted. To do something about them, remove the duplicates: it compares whole rows or just the columns you choose, keeps the first copy of each, and can save the removed rows to a second file so you can see what went. For a mailing list, where the same address arrives with different capitals and stray spaces, removing duplicate emails from a CSV list covers the options worth ticking.
Values Your Importer Will Change Without Telling You
Some rows import perfectly and still arrive wrong, because the damage happened before the import — usually in a spreadsheet, between the export and the upload. These checks exist to tell you what is at risk in this file while it is still intact.
Leading zeros. 00742 is a ZIP code; 742 is not. Open the CSV in Excel and the zeros are gone from the display, and saving the file writes that loss into the file itself. Stop Excel removing leading zeros from CSV files has the four ways to keep them.
Long numbers. Excel keeps 15 significant digits. A 16-digit card number, IMEI or order reference comes back with a zero where the sixteenth digit was, permanently, and it looks like a number rather than an error. Stop Excel turning long numbers into scientific notation explains the difference between the display problem and the destructive one.
Dates. 03/04/2026 is the third of April in one country and the fourth of March in another, and nothing in the file says which. A column holding more than one date format is reported, because it usually means part of the file was reformatted somewhere along the way. Exporting dates as 2026-03-18 removes the ambiguity for good.
RowSlice reads the raw text of your CSV and never opens it as a spreadsheet, so what the report shows is what is in the file. If a value is already wrong here, it was wrong before it arrived.
When the File Is Too Big for the Importer
Some failures are not about the contents at all. Import screens cap the number of rows or the size of the upload, and a file over the cap is refused with no detail about why. The CSV analyzer gives you the exact record count and the file size to compare against the limit, and then you can split the CSV into parts that fit — the header is repeated at the top of every part, and no row is ever cut in half. How to split a CSV to fit an import limit has the published limits for common tools and how to work out the split. The analyzer is also where to go for a fuller picture of what is in the file: every column, its filled and empty counts, its shortest and longest value and its inferred type.
What This Tool Does Not Do
It reports. It does not rewrite your file, correct a value, add a quote or drop a row; there is no fix everything button, because most of these problems have more than one right answer and only you know which. What it writes, if you ask for it, is a separate CSV of the rows three of the checks flag: rows with the wrong number of columns, rows holding a control character, and rows that repeat a value in the ID column you chose. The other checks report a count and up to five examples on screen instead, and nothing of theirs goes into that file.
It does not validate against a schema. It has no idea which columns your importer requires, which types it expects or which values it allows, and there is nowhere to give it a template. Nor does it know how many rows or megabytes your importer accepts, though the maximum rows and file sizes common importers publish are listed side by side, each with its source. It does not check business rules — whether a price is plausible, whether a customer reference exists in your system, whether a country code is one you trade in. It does not check whether an email address is deliverable, or even well formed; it counts blanks and repeats in the column you nominate, and that is the honest extent of it. It reads one file, not two: when the question is what moved between last month's export and this one, see what changed between the two instead.
It is not a spreadsheet either. The validator shows the first rows of the file as a preview and then reports on the whole of it; there is no grid to scroll through and no filtering. To read the rows a count refers to, open the file in the viewer, which pages through a CSV of any size and jumps to the data row number the report gives. What the validator is for is the twenty minutes between an import failing and you finding out why.
Last updated .