CSV Wrong Line Breaks? Fix CRLF vs LF Errors in 60 Seconds

Your CSV opens fine in Excel. The data looks correct. You upload it to Salesforce, MySQL, or your import tool — and immediately get rows merged together, mysterious blank rows between every record, or an outright parse failure at line 1.

No column errors. No encoding warnings. Just broken data.

The cause is almost always invisible: your file has the wrong line endings for the platform you're importing into. Windows, macOS, and Linux all use different characters to mark the end of a row, and when they don't match what your import tool expects, the parser misreads the entire file structure.

This is one of the most common CSV import problems we see — and one of the fastest to fix once you know what's happening.

Before running through fixes manually, you can detect and correct line ending issues automatically with the Delimiter & Encoding Tool — it identifies and normalizes CRLF, LF, and CR endings without uploading your file.

For a complete taxonomy of CSV import failure types, see our CSV import errors complete guide.

Quick symptom check — match your error to the cause:

---

Table of Contents

• What Are CRLF and LF?
• How Line Break Errors Break Your Import
• How to Diagnose Your Line Ending Type
• Step-by-Step Fix Guide
• Platform-Specific Behavior
• The Mixed Line Endings Problem
• Prevention: Export Settings That Get It Right
• FAQ

---

What Are CRLF and LF?

Every row in a CSV file ends with one or more invisible control characters. These characters tell the parser "this row is done — start the next one." The problem is that different operating systems have used different characters for this purpose since the 1970s.

There are three variants in practice:

CRLF (Carriage Return + Line Feed) is what Windows uses. The name comes from typewriter terminology — CR moves the print head back to the start of the line, LF scrolls the paper up one row. Windows kept both characters to move to a new line.

LF (Line Feed only) is what modern macOS and all Linux systems use. Every file you save in a Mac terminal, export from a Linux server, or generate with Python on Unix will use \n only.

CR (Carriage Return only) is a relic of classic Mac OS before OS X (2001). You'll occasionally still encounter it in very old exported files or legacy systems.

RFC 4180 — the closest thing CSV has to an official standard — specifies CRLF as the required row terminator. In practice, most modern parsers accept either CRLF or LF. But "most" is not "all," and when a parser is strict, wrong line endings cause silent, hard-to-diagnose failures.

[Screenshot: Notepad++ showing line ending indicators (CRLF vs LF) in the status bar — before and after conversion]

---

How Line Break Errors Break Your Import

Line ending mismatches produce a small set of repeatable failure patterns. Match your symptom to the cause:

The blank-rows symptom is particularly common with Windows-generated files imported into Linux-based platforms. The import tool strips \n as the row terminator but doesn't strip the \r, which then appears as an empty row.

The single-row symptom — where your entire 50,000-row file reads as one enormous field — almost always means CR-only line endings hitting a modern parser. As one RFC 4180 validation guide notes: CR-only line endings are not supported by compliant parsers and will cause the file to be treated as a single line.

---

How to Diagnose Your Line Ending Type

You can't see line endings in Excel or a standard text editor. You need a tool that can reveal them.

Option 1 — SplitForge (no upload, instant)

Run your file through the Delimiter & Encoding Tool. It detects and reports CRLF, LF, and CR endings and lets you convert in-browser with zero data leaving your machine.

Option 2 — Notepad++ (Windows)

Open the file. Go to View → Show Symbol → Show All Characters. You'll see CR LF markers at the end of each row if CRLF, or LF only if Linux-style. Check the status bar at the bottom — it shows the line ending type directly.

Option 3 — VS Code

Open the file. Look at the bottom-right of the status bar. It shows CRLF or LF for the current file. Click it to toggle and convert.

Option 4 — Command line (Linux/Mac)

# Check line ending type
file yourfile.csv
# "ASCII text" = LF only
# "ASCII text, with CRLF line terminators" = Windows CRLF
# "ASCII text, with CR line terminators" = old Mac CR only

# Check with xxd (shows hex)
head -1 yourfile.csv | xxd | tail -2
# Look for 0d 0a (CRLF), 0a alone (LF), or 0d alone (CR)

Option 5 — Python (one-liner diagnosis)

with open('yourfile.csv', 'rb') as f:
    sample = f.read(2000)
    
if b'\r\n' in sample:
    print("CRLF (Windows)")
elif b'\r' in sample:
    print("CR only (old Mac)")
else:
    print("LF only (Unix/Linux/Mac)")

[Screenshot: VS Code status bar showing "CRLF" line ending indicator bottom-right, with cursor over it]

---

Step-by-Step Fix Guide

Step 1 — Identify your target platform's requirement.

Before converting, know what you're converting to. Most modern web platforms and Linux-based systems expect LF. Windows tools and some legacy CRMs expect CRLF. RFC 4180 specifies CRLF. When in doubt, CRLF is the safer choice for maximum compatibility.

Step 2 — Use SplitForge's Delimiter & Encoding Tool (fastest path).

Open the Delimiter & Encoding Tool, upload your file, select your target line ending type (CRLF, LF, or CR), and download the converted file. The entire operation runs client-side — your data never leaves your browser. This matters if you're working with customer data, PII, or anything subject to GDPR or HIPAA.

Step 3 — Fix with Python if you prefer code.

The most common Python mistake with CSV line endings is opening the file without newline=''. Python's file I/O layer translates \r\n to \n on Windows by default, which hides the problem — until you move the script to Linux or deploy it to a server.

import csv

# WRONG — Python's universal newlines mode hides \r characters
with open('input.csv', 'r') as f:
    reader = csv.reader(f)

# CORRECT — pass newline='' so the csv module handles line endings
with open('input.csv', 'r', newline='', encoding='utf-8') as infile, \
     open('output.csv', 'w', newline='\r\n', encoding='utf-8') as outfile:
    reader = csv.reader(infile)
    writer = csv.writer(outfile)
    for row in reader:
        writer.writerow(row)

The newline='' parameter on the reader prevents Python from pre-translating line endings before the csv module sees them. The newline='\r\n' on the writer ensures RFC 4180-compliant output regardless of the OS you're running on. This behavior is documented in the Python csv module reference — the note about opening files with newline='' is easy to miss but critical for cross-platform reliability.

Step 4 — Fix with sed or tr (Linux/Mac command line).

# Convert CRLF to LF
sed -i 's/\r//' yourfile.csv

# Alternative using tr
tr -d '\r' < input.csv > output.csv

# Convert LF to CRLF (less common — for Windows-strict tools)
sed -i 's/$/\r/' yourfile.csv

Step 5 — Fix in VS Code or Notepad++ (GUI, no code needed).

In VS Code: Click the CRLF / LF indicator in the bottom-right status bar and select the target format. Then save. The file is converted in-place.

In Notepad++: Edit → EOL Conversion → Convert to LF (or CRLF). Save. Done.

Step 6 — Validate the fix before re-importing.

After conversion, re-open the file and verify the line ending type has changed using the same diagnostic method from Step 1. Then re-run your import. If you were seeing blank rows or merged rows, they should be gone.

---

Platform-Specific Behavior

Salesforce

Salesforce's Data Import Wizard and Data Loader both handle CRLF and LF in most cases. The specific failure you'll encounter is when a field value contains an unquoted line break — Salesforce reads it as a new record, splitting one row into two. The fix is to ensure any field containing multi-line text is wrapped in double quotes before import, per RFC 4180 rule 6.

Salesforce itself exports with CRLF. When round-tripping data (export → edit → re-import), the safest approach is to preserve the CRLF from the export.

MySQL / MariaDB

MySQL's LOAD DATA INFILE uses LINES TERMINATED BY to specify the line ending explicitly:

-- For LF-only files (Linux exports)
LOAD DATA INFILE '/path/to/file.csv'
INTO TABLE my_table
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n';

-- For CRLF files (Windows exports)
LOAD DATA INFILE '/path/to/file.csv'
INTO TABLE my_table
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\r\n';

Getting this wrong is one of the more frustrating MySQL import errors because the failure mode depends on which line ending your CSV actually has versus which terminator you specified. If they don't match, MySQL either imports zero rows or imports garbled data with \r embedded in field values. The full LINES TERMINATED BY syntax is covered in the MySQL LOAD DATA INFILE documentation.

Python / pandas

Pandas read_csv() is generally tolerant of both CRLF and LF, but you can encounter double-newline issues on Windows when writing. The safe pattern for pandas on any OS:

import pandas as pd

# Reading — pandas handles both CRLF and LF automatically
df = pd.read_csv('input.csv')

# Writing — explicitly set lineterminator to avoid OS-dependent behavior
df.to_csv('output.csv', index=False, lineterminator='\n')
# or for RFC 4180 compliance:
df.to_csv('output.csv', index=False, lineterminator='\r\n')

The lineterminator parameter (renamed from line_terminator in pandas 1.5.0) ensures consistent output regardless of whether you're on Windows, Linux, or macOS. See the pandas DataFrame.to_csv documentation for the full parameter reference.

HubSpot

HubSpot's contact and deal import accepts both CRLF and LF without issues. Line break errors are more likely to surface if you're importing notes or description fields that contain literal line breaks in the data. Wrap those fields in quotes to prevent HubSpot from treating the embedded newline as a row terminator.

[Screenshot: MySQL workbench import error showing garbled row data caused by CRLF mismatch]

---

The Mixed Line Endings Problem

The worst-case scenario is a file with mixed line endings — some rows ending in \r\n, others in \n, occasionally one with just \r. This usually happens when:

• Multiple people edited the file on different operating systems
• A script appended rows without normalizing line endings
• Two CSV files were concatenated in a text editor that didn't standardize endings
• An export tool changed behavior partway through generating the file

As Row Zero's CSV error guide notes, many tools are flexible and accept both LF and CRLF separately — but may fail if they both appear in the same file. This is the edge case that even lenient parsers choke on.

Mixed line endings are hard to spot visually and hard to fix with simple sed commands because you need to normalize rather than replace. The cleanest fix:

# Normalize mixed line endings to LF
with open('messy.csv', 'rb') as f:
    content = f.read()

# Replace all CRLF first, then any remaining CR
normalized = content.replace(b'\r\n', b'\n').replace(b'\r', b'\n')

with open('clean.csv', 'wb') as f:
    f.write(normalized)

Order matters: replace \r\n before \r. If you replace \r first, the \r\n sequences become \n\n — double newlines, which creates blank rows.

The Delimiter & Encoding Tool handles mixed line ending normalization automatically.

---

Prevention: Export Settings That Get It Right

The best fix is not needing one. A few export habits that prevent line ending mismatches at the source:

When exporting from Excel on Windows: Excel uses CRLF by default, which is RFC 4180 compliant. Leave it. Most platforms handle CRLF correctly. If your target is Linux/Mac-only tooling, convert after export.

When writing Python scripts that generate CSVs: Always specify newline='' on the file open and set an explicit lineterminator in your csv.writer. Never rely on OS defaults — they change when you deploy.

When exporting from Linux servers or Mac terminals: Your shell tools produce LF by default. Most modern platforms accept LF, but if you're targeting Salesforce Data Loader, CRLF is safer.

When your data contains multi-line field values: Always quote those fields. Per RFC 4180, line breaks inside fields must be enclosed in double quotes. Unquoted embedded newlines are guaranteed to corrupt your row structure on import regardless of which line ending type the file uses.

For related encoding issues that show up alongside line break errors, see our guides on BOM characters in CSV files and escaped quotes breaking CSV import.

If you're not sure which error type you're dealing with, the CSV import errors complete guide walks through diagnostics for all 25+ import failure patterns. You can also run your file through the Data Validator for automatic detection of delimiter, encoding, structure, and line ending issues in one pass.

---

FAQ