When a Line Break Inside a Cell Splits One CSV Row Into Many

Updated July 2026 · By the CSVUndo team · 6 min read

The quick answer: A CSV field is allowed to contain a line break — but only when that field is wrapped in double quotes. That is the rule set out in RFC 4180. When a multi-line address or a notes field is written without quotes, the reader hits the newline sitting inside your cell and assumes the record has ended, so one row splits into two or three and every row below it slides out of alignment. The dependable fix is to re-export the file from its source with proper quoting — almost every exporter, Excel’s own Save As CSV included, quotes fields that contain a newline automatically. If you truly can’t re-export, replace the in-cell newlines with a space before the next system reads the file.

Why one line break splits a row into many

A CSV file is line-based: normally, each record ends where a line ends. That works until a single field genuinely needs a line break of its own — a mailing address split across three lines, or a free-text notes column. The format has one escape hatch for that case, and it is double quotes. When the field is quoted, the reader keeps everything between the quotes, newline and all, as one value. When it is not quoted, the reader can’t tell your intentional in-cell newline apart from a real end-of-record newline — so it stops the record early. The text after the break becomes the start of a new row with the wrong number of columns, and every following record inherits the shift.

That is why the damage looks bigger than its cause: one address with an unquoted line break can misalign the entire rest of the file, because every later record is now counted from the wrong starting point.

The RFC 4180 quoting rule, in one table

The whole thing comes down to four cases. RFC 4180 says a field must be quoted whenever it contains a line break, a double quote, or a comma; otherwise it can be left bare. This is the table to keep next to you:

So a three-line address should appear in the raw file as one quoted block, with the line breaks living between the opening and closing quote: "12 High Street\nUnit 4\nLondon". A compliant parser reads that as a single cell containing two newlines — not three rows. Strip the quotes and the same bytes produce three rows. Those two quote marks are the entire difference between a clean file and a broken one.

Best fix: re-export from the source

If you can go back to where the file came from, do that first — it is the only fix that is guaranteed correct. Whatever produced the CSV (a database, a CRM export, a spreadsheet) still holds the field boundaries intact, so it can re-emit the file with the newlines properly quoted.

1. Open the original system or spreadsheet that produced the data.
2. Export to CSV again. In Excel, use File → Save As and choose a CSV format — it quotes any cell containing a line break automatically.
3. Open the new file in a plain-text editor and confirm the multi-line fields start and end with a double quote, with the break sitting inside.

Re-exporting works because the quoting is added while the data still leaves a system that knows where each field begins and ends. Once that structure is lost in a badly written file, no amount of editing fully rebuilds it — the honest limit covered further down.

If you can’t re-export: flatten the newlines at the source

If you just need one line per record, the reliable way to remove the in-cell breaks is where the file is produced — not with a blind find-and-replace afterwards. The catch is that in a plain-text file a newline inside a cell and a newline that ends a record look identical; only the surrounding quotes tell them apart. So a naive editor search that replaces every newline will also merge your genuine rows. Flatten them in a place that knows the difference:

• In the source query or spreadsheet, before exporting. Strip the break out of the data itself with a formula — =SUBSTITUTE(A2,CHAR(10)," ") in Excel or Google Sheets (add CHAR(13) as well if needed) — then export to CSV. Replace it with a space, or a marker such as a pipe (|) if you want to rebuild the lines later.
• In a CSV-aware editor or script that understands quoting, so it only touches newlines inside quoted fields and leaves the record breaks alone. A plain Notepad find-and-replace cannot make that distinction — it will merge records — so don’t use it for this.

When the rows have already split: what’s recoverable

Here is the blunt truth: if the file was saved with unquoted newlines and nothing marks where each field started and ended, re-joining the split rows is guesswork. A parser has already turned one record into several, and the information that said “these three lines were one address” was never written down. You can sometimes stitch rows back together if a reliable signal survives — for example, every real record starts with an ID in the first column, so any row missing that ID must be a continuation of the one above it. Where that kind of pattern holds, the join is mechanical and safe.

Where no such signal exists, any reconstruction is a judgement call, and a judgement call on data is a quiet way to introduce errors. In that situation the right answer is not a clever script — it is to re-export from the source, as above. If the source is genuinely unavailable, treat the salvaged file as approximate and flag it for human review rather than trusting an automatic re-join.

Note that this is a different issue from your file’s overall line endings (CRLF vs LF) — whether records end in CRLF or LF is a whole-file property and a separate problem from a stray break inside a single field. If every value has collapsed into a single column instead, that is usually a delimiter mismatch; see why all your CSV data lands in one column.

How this differs from a comma breaking your columns

Same cure, different symptom. The line-break problem and the embedded-comma problem are two faces of the identical RFC 4180 rule, but they fail in visibly different directions:

An unquoted comma inside a field is read as a column separator, so a single cell such as Smith, John splits into two columns on the same row — the row gets too wide. An unquoted line break is read as a record separator, so the field splits into two rows — the file gets too tall and everything below shifts down. Wrapping the field in double quotes fixes both at once, because quotes tell the reader “treat everything in here literally.” If commas are your actual culprit, the dedicated walkthrough is commas in a CSV breaking your columns. If you want the full rulebook, both symptoms trace back to the same short specification linked at the foot of this page.

Frequently asked questions

Sources: the quoting rules for line breaks, commas and double quotes are defined in RFC 4180. Real-world reports of line breaks splitting CSV rows on import are discussed in the Microsoft Learn Q&A.