CSV Line Endings Explained: CRLF vs LF (and How to Fix Them)
The quick answer: Three different-looking problems — a visible ^M at each line end, a blank row between every record, or your whole file crammed onto one giant line — are the same fault in disguise. Every row in a text file ends with an invisible marker, and yours doesn’t match what the tool reading it expects. Windows ends rows with CRLF (\r\n), Unix, Linux and modern macOS use LF (\n), and very old Macs used CR (\r) alone. The fix is to normalize the file to one convention: in Notepad++ use Edit → EOL Conversion; in VS Code click the CRLF/LF button in the status bar; on the command line run dos2unix or unix2dos. This is not a line break inside a quoted cell — that is real data, covered separately.
Match your symptom to the cause
A CSV is plain text, and the only thing separating one row from the next is an invisible end-of-line marker. Three exist, from different eras: CR is a carriage return (the typewriter action of sliding back to the left margin), LF is a line feed (rolling the paper up a line). Windows kept both, Unix uses the line feed alone, classic Macs the carriage return alone. When the file’s marker doesn’t match what your tool assumes, you get one of these:
| Convention | Bytes | Typical symptom when mismatched |
|---|---|---|
| CRLF (Windows) | \r\n | Read by a tool that breaks on \n only, the leftover \r shows as a stray ^M at each line end. Read by one that treats \r as a row break as well, the same pair looks like two breaks → a blank row between records |
| LF (Unix/Mac) | \n | Usually fine everywhere; a strict Windows importer may run rows together |
| CR (classic Mac) | \r | No \n exists, so a tool expecting \n finds no row breaks → the whole file lands on one line |
Read your symptom straight off that table: a trail of ^M characters is a stray carriage return from a CRLF file, shown literally by vim, less or a Unix terminal; a blank row between every record is the opposite reader: one that counts \r and \n as separate row terminators, so each \r\n pair looks like two line breaks with nothing between them (a file that has been converted twice and now holds a real \r\r\n does the same thing to any reader); and a file that opens as one endless line is a CR-only export opened where only \n counts as a break. In every case the data is intact — only the row markers are misread.
Row terminator vs. a break inside a cell
Before you change anything, confirm this is a line-ending problem and not a legitimate line break inside a field. The two look similar but are opposites. A line ending is the row terminator: it marks where one record stops and the next begins. A newline inside a quoted cell (a two-line address, a paragraph break in a comment) is data, wrapped in double quotes so the parser keeps it together. Normalizing line endings is safe and reversible; deleting an in-cell newline destroys real content. So if your “extra” rows appear only inside a quoted value, that is the in-cell case — see line breaks inside CSV cells instead, and leave the row terminators alone.
How to normalize the line endings
Pick one convention and rewrite the whole file to it — that is the entire fix. You don’t edit rows by hand; a text editor swaps every marker in one command. The quickest route, in Notepad++:
- Open the CSV in Notepad++. The current ending shows at the bottom-right (Windows, Unix or Macintosh).
- Open Edit → EOL Conversion.
- Choose Windows (CR LF), Unix (LF) or Macintosh (CR) — every row is rewritten to match.
- Save the file. The
^Mcharacters, blank rows or single-line collapse are gone.
In VS Code it is even faster: the status bar shows CRLF or LF; click it, pick the other, save. On the command line, dos2unix file.csv makes a Unix (LF) file and unix2dos file.csv the Windows (CRLF) version. Apply it to the whole file — a mixed half-CRLF, half-LF file causes the same symptoms again.
Blank row between every record? Strip them in the browser
If the mismatch has left an empty line between each record and you can’t open the file in an editor, our free CSV cleaner re-parses it and drops every blank row in one pass — all locally, nothing uploaded. It is a fast patch for that one symptom; normalizing the line endings above is still the root-cause fix.
Open the CSV cleaner →🔒 Your file never leaves this tab — we can’t read, store or leak what we never receive. See the proof →
Why databases and Git care about it
Line endings feel cosmetic until a machine reads the file. Database bulk-import tools — LOAD DATA in MySQL, COPY in PostgreSQL, the SQL Server import wizard — are told exactly which byte ends a row; the wrong one makes them fail or glue two rows together with a stray \r on the last column. A CSV that looks perfect in an editor can still be rejected, because the importer reads bytes, not appearances.
Git cares because its diff and merge tools work line by line. The warning “LF will be replaced by CRLF the next time Git touches it” is Git’s autocrlf setting normalizing endings between your Windows checkout and the repository’s stored LF. Left unmanaged, an ending change can make Git report that every line changed, burying your one real edit. Settle on a single convention and keep it, and both databases and version control stay quiet.
Frequently asked questions
What does ^M mean in my CSV?
^M is how Unix tools, vim and some terminals display a stray carriage return (\r) left over from Windows CRLF endings. The file ends each row with two bytes (\r then \n), but the tool only expects \n, so it shows the orphaned \r as a visible ^M. Convert the file to Unix (LF) with dos2unix or your editor’s EOL conversion and the ^M characters disappear.
Why is there a blank row between every row of my CSV?
Your reader is counting the carriage return and the line feed as two separate row terminators, so each \r\n pair looks like two line breaks with an empty record between them. The other common cause is a file converted twice, which now genuinely holds \r\r\n at each row end. Either way it is the same family of CRLF-versus-LF mismatch as the ^M symptom — that one is a reader that breaks on the line feed alone and leaves the \r sitting at the end of the row. Normalize the file to one convention (all LF or all CRLF) and the phantom rows vanish; a CSV cleaner that drops blank rows also strips them as a quick patch.
Why is my whole CSV on one line?
The file almost certainly uses CR-only line endings — a classic (pre-2002) Mac export — opened in a tool that only recognises \n as a row break. Because it never finds an \n, it treats the whole file as one enormous line. Convert the endings to Unix (LF) or Windows (CRLF) in a text editor and the rows separate again; your data is intact, only the markers are unexpected.
What line ending should a CSV use?
RFC 4180, the informal CSV specification, says each record should end with CRLF, so CRLF is the safest default — especially for Windows software and database bulk-import tools. That said, LF is widely accepted by modern spreadsheets, scripts and databases, and is standard on Unix and macOS. What matters most is consistency: pick one convention and use it throughout the file.
Sources: the line-ending symptoms and command-line fixes in SplitForge’s CRLF line-break error guide; the CRLF row-terminator recommendation from RFC 4180, the Common Format and MIME Type for CSV Files. Related: changing a CSV’s encoding to UTF-8, the UTF-8 BOM and Excel, and all guides.