CSV Line Endings: CRLF vs LF (and Why Imports Complain)

Every text line ends in an invisible marker. Windows uses two characters — CR then LF (\r\n, "CRLF"). Linux, macOS, and modern tooling use one (\n, "LF"). Classic Mac OS used bare CR. Files bouncing between systems can end up with any mix of the three.

Where the trouble shows up

• Row counts off by one: a file with a lone \r at the end registers an extra phantom row.
• Values with hidden \r: naive splitters leave a carriage return glued to the last column, so "active\r" never equals "active" in comparisons or joins.
• Strict loaders: some database importers reject or misalign files whose endings differ from their expectation.
• Diff noise: every line shows as changed when two teams' tools disagree on endings.

The symptoms overlap with quoting and encoding damage, which is why we recommend starting from diagnose CSV file errors rather than guessing.

Checking your file

CSV Diagnostic reports the detected line-ending style — CRLF, LF, or CR — alongside delimiter, encoding, and structural issues. If the report says "CRLF" and your target system wants LF, that is your answer in ten seconds.

Normalizing

Any round-trip through HappyCSV normalizes output: Repair CSV, Trim Whitespace, or even a plain view-and-download via CSV Editor re-emits consistent endings. For surgical changes without touching data, use Find and Replace: search for \r behavior by enabling regex mode in Regex Replace.

Which should you export?

Modern default is LF everywhere except when a Windows-only consumer demands CRLF. RFC 4180 technically specifies CRLF for CSV, but in practice parsers accept both; consistency within the file matters more than which style you pick.

Real bugs caused by endings

These three consume support inboxes everywhere:

• The join that never matches: keys ending in invisible \r never equal clean keys, so Join CSV reports zero matches on visibly identical columns. Trim whitespace (guide) fixes it.
• The off-by-one row count: last line without a trailing newline, or a stray bare CR mid-file, makes loaders report N±1 rows and breaks reconciliation checks.
• Git saying everything changed: mixed endings make version control flag untouched files wholesale, hiding real diffs.

Setting endings per environment

• git: git config core.autocrlf input (commit LF, checkout as-is) prevents cross-platform churn in repos storing CSVs.
• Editor defaults: VS Code shows the current ending in the status bar and converts via one click — worth checking before exporting "cleaned" files back out.
• Windows tooling that demands CRLF: some legacy loaders genuinely require it; give them CRLF deliberately rather than mixing.

Normalizing without touching data

The safest conversions change nothing but the endings:

1. Confirm current state with CSV Diagnostic — it names the style explicitly alongside delimiter and BOM findings.
2. Round-trip once through Repair CSV; output uses consistent endings and preserved quoting.
3. Verify with a second diagnostic pass plus a row-count comparison against the source.

If values themselves carry trailing carriage returns (the join-killing case), Trim Whitespace strips them cell-by-cell while leaving real content intact.

The rule worth adopting

Pick one style per pipeline — modern default LF — and normalize at ingestion like encoding. Endings are metadata masquerading as content; the moment you stop letting individual desktops decide them, the bug class disappears from your queue.

FAQ

Which ending should my API emit? LF, with a trailing newline on the final row. It is the modern default and what diff tools expect.

Can a single file mix endings legally? Parsers accept it, which is the problem — the file works until one strict consumer or naive splitter meets the odd line out. Normalize instead.

Did old Mac CR files really exist? Classic Mac OS (pre-OS X) used bare CR; files from that era still surface in archives. Modern tooling treats them as one giant line, so conversion is required before anything else.