CSV Line Endings Explained: LF vs CRLF

A CSV file is plain text laid out in rows, and something has to mark where one row stops and the next begins. That marker is the line ending, an invisible character (or pair of characters) at the end of every line. Most of the time you never think about it, until a file arrives full of strange ^M symbols or collapses into a single endless line. Almost always the culprit is a mismatch between two conventions: LF and CRLF.

Where LF and CRLF come from

The split goes back to the typewriter. To start a new line, a typist did two things: a carriage return moved the carriage back to the left margin, and a line feed rolled the paper up one row. Early computers inherited both motions as two separate control characters: carriage return (CR, byte \r, or ^M) and line feed (LF, byte \n).

When operating systems standardized, they disagreed on how many of those characters a newline should be:

• Unix (and later Linux and modern macOS) chose a single LF (\n). One byte, clean and simple.
• Windows, following the older DOS and CP/M tradition, kept both as CRLF (\r\n). Two bytes per line.
• Classic Mac OS (before OS X) used a lone CR (\r), a third style you still occasionally meet in old files.

That history is the entire reason a "just plain text" CSV can behave differently depending on which machine wrote it.

LF vs CRLF at a glance

Aspect	LF	CRLF
Characters	\n (line feed)	\r\n (carriage return + line feed)
Bytes per line ending	1	2
Escape sequence	\n	\r\n
Origin	Unix, Linux, modern macOS	Windows, DOS
Common symptom when wrong	File opens as one long line	Stray ^M at line ends

Neither style is "correct" in the abstract. Each is simply what a given platform expects. Problems start only when a file made for one convention is read by a tool that assumes the other.

The symptoms of the wrong line ending

Because the difference is invisible in a well-behaved editor, you usually discover a line-ending problem by its side effects.

Stray ^M characters

Open a Windows-made CRLF file in a Unix tool that expects plain LF, and you may see a ^M (or a literal \r) clinging to the end of every line. The tool treats the LF as the real line break and has no idea what to do with the leftover carriage return, so it shows it as a visible stray character. In a CSV that can mean every value in the last column secretly ends with an invisible \r, which then breaks comparisons, lookups, and joins downstream.

Everything on one line

The opposite mismatch is just as common. A file saved with only LF endings, opened in a tool that recognizes only CRLF, never encounters a line break it understands. The result is one enormous line with the whole dataset jammed together. Old CR-only files cause the same effect in modern editors that expect LF.

A parser that simply refuses

Some stricter importers don't try to guess. If they expect CRLF and get LF (or the reverse), they may report a malformed file, miscount rows, or merge records together. The data is fine; the row boundaries just aren't where the parser is looking.

Why it matters for CSV interchange

CSV exists to move tabular data between systems, and those systems rarely share an operating system. A report exported on a Windows server, processed on a Linux machine, and opened on a colleague's Mac crosses all three conventions in a single trip. If each hop assumes its own newline, the file accumulates stray carriage returns or loses its row breaks along the way.

This is also why robust tools handle line endings as a deliberate choice rather than a silent default. Getting the delimiter right is one half of clean interchange; getting the line endings right is the other. Both have to match what the receiving system expects, the same way the delimiter and the character encoding do.

How to convert line endings on export

The good news is that fixing line endings is just a matter of rewriting the file with the convention the destination wants. The catch is that many tools never give you the choice; they save in whatever their platform defaults to and leave you to clean up the mismatch afterward.

CEESVEE makes it explicit. When you open a delimited file it reads LF, CRLF, or CR endings without complaint and shows clean rows in the grid. On Save or Save As, it lets you pick the line ending you want, LF or CRLF, directly, alongside the delimiter, the character encoding, the quoting style, and whether to write a byte-order mark. So if you receive a CRLF file that a Linux pipeline needs as LF, you open it, choose LF on save, and you're done. No stray ^M, no one-line files, no hunting for a separate conversion utility.

Because CEESVEE is a fast, free, open-source viewer and editor with a Rust core, that round-trip stays quick even on large files, up to a million rows and well past 100 MB. Everything happens locally on your own machine, so converting line endings is a single deliberate step you control, not a guess.

The bottom line

LF (\n) and CRLF (\r\n) are two answers to the same small question of how to end a line, one inherited from Unix and one from Windows. The difference is invisible until a tool reads the wrong convention, at which point you get ^M characters, a file mashed onto one line, or a parser that won't cooperate. Knowing which style your destination expects, and being able to save in that style on purpose, turns a recurring annoyance into a non-issue.

Download CEESVEE for free and choose LF or CRLF explicitly every time you save, so your CSVs land clean on whatever system reads them next.