CSV file inspector: encoding, delimiter and broken rows
Drop a CSV that will not import and see why: the encoding, the delimiter, the rows with the wrong number of fields, the quote that never closes, the invisible characters and the cells a spreadsheet would run as formulas. The file is read in your browser, so a customer export never leaves your machine.
Runs in your browser: nothing is uploadedEncoding first
Most "corrupt CSV" reports are an encoding mismatch. The inspector checks the raw bytes: a
UTF-8 byte order mark (which Excel wants and many parsers keep as part of the first column name),
UTF-16 (Excel's "Unicode Text" export, which puts a NUL byte between ASCII characters) and bytes that are
not valid UTF-8 at all, usually Windows-1252 from an older export. It gives the offset of the first bad byte,
and flags double-encoded text such as é where é was meant.
Structure
It detects the delimiter from the first rows (comma, semicolon, tab or pipe), then parses the whole file the way RFC 4180 describes, so a quoted field containing commas or line breaks is one field. Rows whose field count differs from the header are listed by line number, as is a quoted field that opens and never closes, which silently swallows the rest of the file in lenient parsers.
What hides in the cells
Zero-width spaces, direction overrides and no-break spaces make two identical-looking values compare
unequal, so a lookup fails for no visible reason. Cells starting with =, +,
- or @ run as formulas when the file is opened in a spreadsheet (CSV injection). Both are
reported with the line they first appear on.
Questions
Is it safe to check a CSV with customer data here?
Yes. The file is read by JavaScript in this page and is never uploaded, logged or stored. You can load the page, disconnect from the network, and it still works.
Why does my CSV show strange characters like é?
The text was UTF-8, something read it as Windows-1252, and it was saved again as UTF-8. Each accented letter became two characters. The inspector flags this pattern; the fix is to re-export from the original with the right encoding, not to patch the characters.
Why does the first column name not match?
Usually a UTF-8 byte order mark at the start of the file. Excel adds it and needs it, but a reader that does not strip it makes the first header an invisible U+FEFF followed by the name you expect.
How big a file can it inspect?
It reads up to the first 50 MB, in your browser's memory. For larger files the findings cover that first part, and the page says so.