A blank line between every row of data, a pile of empty rows at the bottom, or the opposite — everything crammed onto one line. These are almost always line-ending problems, not bad data.
The classic double-spacing bug: the file uses Windows \r\n (CRLF) line endings, and a tool reading it counts the \r and the \n as two separate line breaks — so every real row is followed by an empty one.
Re-save the file with consistent line endings, or open it in a tool that normalizes them. Most modern parsers handle CRLF correctly; the ones that don't are usually older scripts or naive line-by-line splits.
The opposite problem: the file uses bare carriage returns (\r, the old Mac convention) and your tool only recognizes \n, so it never sees a line break and reads everything as a single row.
Normalizing the line endings to \n or \r\n fixes it instantly. A parser that understands all three conventions (like the one here) reads it correctly without any conversion.
One or more empty rows at the bottom of the file usually come from extra newlines at the end of the export. They are harmless to most tools, which skip empty trailing lines, but they can add phantom blank records to a strict import.
Trimming trailing whitespace, or running the file through a parser that ignores empty lines, clears them.
The durable fix is to standardize on one convention — \n (LF) is the most portable, \r\n (CRLF) is what RFC 4180 specifies. Re-save the file with consistent endings, and use a CSV parser that handles quoted fields and mixed endings rather than splitting on newlines yourself.
If you just want the file to load cleanly, drop it here — the parser normalizes endings and skips empty rows automatically, all in your browser.
A CRLF (\r\n) file read by a tool that treats \r and \n as separate line breaks, so each row gets an empty one after it. It's a line-ending mismatch, not a data problem.
Both are valid. RFC 4180 specifies CRLF; Unix tools use LF. What matters is consistency and a reader that accepts your file's convention. Most modern parsers accept either.
Only for that copy. If the export keeps producing CRLF (or CR-only) endings, the issue returns next time. Fixing the line endings at the source — or using a parser that normalizes them — is the real fix.
No. The validator inspects line endings and empty rows entirely in your browser; nothing is sent anywhere.