CSV Validator

Drop a file in or paste the text, and read back a plain report: what is wrong with it, how many times, and which lines to go and look at. Nothing gets corrected on the way through, because a validator that quietly edits your data has stopped telling you the truth about it. The whole check runs in this tab.

Ready to repair what it found? Open the app

The check you wish you had run at row 40,000

An import rarely fails at the start. It runs for four minutes, gets most of the way through, and then stops on a line nobody has ever looked at, with an error message written for the person who built the importer rather than the person feeding it. Every one of these is the same story:

A loader that dies partway and rolls back. Forty thousand rows in, "unexpected end of record", and no line number worth trusting. You need to know before you press go, not after.
A file that came from somebody else's system. Exported from a tool you do not run, by a person who cannot rerun it today. Whatever is in it is what you have to work with, so the first job is finding out what that is.
Accented names that arrived as question marks. Somewhere upstream a file was decoded with the wrong assumption and saved again. The characters are already gone by the time you see them, and it helps enormously to know that early.
A nightly export that quietly changed shape. Same filename, same schedule, one extra column since Tuesday. Nobody announced it, and the downstream job will not either.
A file that opens fine in Excel and nowhere else. Excel is forgiving about ragged rows and stray quotes. Postgres, pandas and every upload form on the internet are not.
A support ticket that says "the upload does not work". Being able to reply with two specific line numbers ends that conversation in one round trip.

There is no shortage of tools that will clean a CSV for you. There are very few that will just tell you what is in it and leave it alone. That distinction matters when the file is evidence: you cannot hand somebody a fixed copy and also explain what was broken about the original.

Worked example: five findings in six lines

The built-in example is small enough to check by eye, which is the point. Click "Try an example" under the box above and this is what goes in as messy.csv:

id,name,name,amount
1,Ada , 100

2,Grace,Hopper,200,extra
3,Alan,Turing,50

Four of those five lines end with a Windows CRLF and one ends with a bare LF, which you cannot see here and neither can your text editor. Here is the report, in full, exactly as it appears on the page and downloads as messy-validation.txt:

CSV validation report
File: messy.csv

PROBLEMS (2)
------------
1. The header uses "name" 2 times (columns 2, 3). Most readers keep only one of them, so the other column is lost.
2. 2 rows do not have the header's 4 columns: line 2 has 3, line 4 has 5.

WARNINGS (3)
------------
1. Mixed line endings: 4 CRLF and 1 LF. Some readers treat the odd ones out as part of the data.
2. 1 completely blank row (line 3).
3. 2 cells have leading or trailing whitespace, which most tools keep as part of the value.

INFO
----
- 3 data rows and 4 columns, plus a header row.
- Separator: comma.
- Line endings: mixed.
- Columns: id, name, name, amount.

Nothing in your file was changed. To fix any of the above, open it in the full editor:
https://exploremydata.com/app

Read the two problems back against the file. Line 2 is 1,Ada , 100, which has three fields where the header promised four, so the amount column on that row is anyone's guess. Line 4 is 2,Grace,Hopper,200,extra, which has five, so a loader will either reject it or drop the last value. The header itself uses name twice, and almost every reader on earth keeps one of those columns and discards the other without comment.

The warnings are the softer trouble. One CRLF file with one stray LF in it will read as five rows in some tools and four in others. The blank line at line 3 is counted as a blank row and excluded from the data-row total, which is why the INFO block says three data rows rather than four. And Ada with a trailing space will not match Ada in any join you write later.

Six lines, five findings, and the file that came out is byte for byte the file that went in.

The nine checks

Every one of these runs on every file, in a single pass, and each finding that has a location carries it:

Ragged rows, with line numbers. Any row whose field count differs from the header's, reported as "line 2 has 3, line 4 has 5". This is the check that predicts an import failure more reliably than any other.
Header names that repeat or are missing. A name used twice is named with the column positions it occupies. A header cell that is empty or nothing but spaces is reported separately, since a column with no name cannot be referred to by anything downstream.
Completely blank rows. Listed by line number and kept out of the data-row count, so the row total in the report is the total you would expect to load.
Mixed line endings, counted. Not just "this file is inconsistent" but "4 CRLF and 1 LF", which tells you whether you are looking at one stray line or a file assembled from two sources.
A UTF-8 byte-order mark. Three invisible bytes at the front of the file that turn your first column name into something no header lookup will match.
Encoding damage. Every U+FFFD replacement character is counted and the lines carrying them are listed. These are not a rendering glitch: the original characters were destroyed when something decoded the file with the wrong assumption, and no tool can recover them from this copy.
Broken quoting, with line numbers. A quote inside a quoted field that was not doubled, which is how one bad cell swallows the rest of the file into a single enormous value.
Cells padded with whitespace. Counted across the file. Leading and trailing spaces survive almost every import and then break every join and every lookup you write afterwards.
Separator confidence. Comma, semicolon, tab and pipe are all counted outside quoted fields. When the runner-up appears about as often as the winner, the report says so and names both, rather than picking one and hoping.

Below all of that sits an INFO block that is not a complaint about anything: how many data rows and columns, which separator won, which line endings, and the full list of column names. On an unfamiliar file that block is often the most useful part of the report.

Why the line numbers are right

A line number is the entire product here. Give someone the wrong one and you have sent them to look at an innocent row, which is worse than saying nothing. Two things routinely break line numbers in other tools, and both are handled before any check runs:

Line breaks inside quoted fields. A postal address in one cell can legitimately span three lines of the file. Counting records and calling that a line number puts every later finding two lines early. The raw text is scanned character by character first, tracking whether the scanner is inside a quoted field, and the real starting line of every record is recorded before anything is parsed.
Mixed line endings. Most CSV parsers detect one line ending and then split on only that one. Feed a mostly-CRLF file with a stray LF to a parser like that and two rows arrive glued together, after which every line number is off by one and one ragged row hides completely. The scan reads the endings off the original text, and the parser then works from a normalised copy whose records line up one for one with what the scan counted.

The result is the case that separates this from most of what you will find: a file that mixes line endings and contains a quoted line break still reports the ragged row at its real line. Put id,name,amount over a quoted two-line name, a short row and a good row, and the finding reads "1 row does not have the header's 3 columns: line 4 has 2". Line 4 is where that short row physically sits.

Gotchas worth knowing

Line numbers are file lines, not grid rows. The header is line 1. A record with a line break inside a quoted cell occupies two lines of the file but one row in a spreadsheet, so the two numbering schemes drift apart on exactly the files where it matters most.
A line break inside a quoted field counts toward the ending tally. A Windows-written file with one LF inside a quoted note will be reported as having mixed endings. That is technically true of the bytes and occasionally more alarming than it deserves, so check whether the odd one out is inside a quoted cell before you go hunting.
Each finding names at most ten lines. Beyond that the list ends with "and 4 more", because a report listing three hundred line numbers is a wall, not an answer. The count at the front of the finding is always the real total.
One broken quote can produce more than one entry. When the parser loses the thread it reports each place it noticed, so a single unescaped quote sometimes shows up twice for the same line. Fix the line, not the count.
The trailing newline is not a blank row. Nearly every correctly written CSV ends with one, so it is treated as punctuation. A genuine empty line in the middle of the file is still reported.
Short files confuse separator detection. Two lines of tab-separated text can be read as one column of commas. The separator-confidence warning is what flags it, and a handful more rows resolves it.
Only structure is checked, not meaning. There is no schema, no type checking and no rule that says a date column must hold dates. A file can come back with no findings at all and still be full of nonsense.
An empty file is an error, not a clean bill. Nothing to check gets said out loud rather than reported as a pass.

Frequently Asked Questions

Does the validator fix my file?

No, and that is deliberate. It reads the file and writes a report about it. Your data is never rewritten, re-quoted or re-encoded, so nothing can be silently changed on the way through. The report ends with a link to the full editor, which is where fixing happens once you have decided what needs fixing.

Why does the report say line 4 when my spreadsheet shows row 3?

Because these are line numbers in the file, not row numbers in a grid. The header is line 1, blank lines are counted, and a field containing a line break spreads one record over two lines. That is exactly what you want when the next step is opening the file in a text editor and jumping to the line.

What is the difference between a problem and a warning?

A problem will change what another program reads: rows with the wrong number of columns, a header name used twice, a header cell with no name, broken quoting, characters already lost to a bad decode. A warning is something a reader may or may not cope with, such as a byte-order mark, mixed line endings, blank rows or cells padded with spaces. Both are counted separately at the top of the report.

It says the separator might be wrong. What does that mean?

The separator is detected, not declared, so the report says which character it settled on and how many times it appears outside quotes. If a rival character appears about as often, you get a line naming both. A European export using semicolons with comma decimals is the usual cause, and the message tells you which one to suspect if the columns look wrong.

Can I check a TSV or a semicolon-separated file?

Yes. Comma, semicolon, tab and pipe are all sniffed, and the report names the winner in its INFO block. Very short files give the sniffer little to work with, so a two-line TSV can be read as a single column; the separator-confidence line is the tell, and pasting a few more rows settles it.

Is my file uploaded anywhere?

No. The file is read in your tab, checked there, and the report is assembled there. There is no upload endpoint behind this page, no account and no history. Checking a payroll extract or a customer list here leaves no copy anywhere but your own machine.

Check a CSV before it checks you

Free, no account, nothing uploaded, nothing changed. Paste the file or drop it in and read the report.

Back to the validator