Under RFC 4180, a CSV field must be wrapped in double quotes whenever it contains a comma, a double quote, or a line break, and a literal double quote inside a quoted field is escaped by doubling it. CSV looks trivial until a value contains one of those three characters, at which point naive splitting on commas corrupts the data. This article covers the actual escaping rules, works through the tricky cases, and explains why CSV files still break between tools despite a document describing how they should behave.
What is RFC 4180 and is it a real standard?
RFC 4180 is a 2005 memo that documents the most common conventions for comma-separated values, but it describes existing practice rather than imposing a binding standard that every tool must obey. Before it, CSV was purely folklore, and each program did roughly what it liked. The RFC wrote down the rules that most implementations already broadly agreed on: fields separated by commas, records separated by line breaks, optional double-quote wrapping, and a specific way to escape quotes. It is useful precisely because it gives everyone a common reference. It is important, though, not to treat it as a guarantee. Plenty of tools deviate: they use semicolons instead of commas in locales where the comma is a decimal separator, they emit different line endings, or they handle encoding their own way. RFC 4180 tells you how well-behaved CSV should look, not how every file you receive actually looks.
When does a field need to be quoted?
A field must be enclosed in double quotes if and only if it contains one of three special characters: a comma, a double quote, or a line break. Any field free of all three can be written bare. The table below shows the rule applied to concrete values.
| Raw value | Needs quotes? | How it appears in the file |
|---|---|---|
web |
No | web |
New York, NY |
Yes (comma) | "New York, NY" |
She said "hi" |
Yes (quote) | "She said ""hi""" |
| a value with a line break |
Yes (newline) | "a value with aline break" |
spaces |
Optional | " spaces " |
Leading and trailing spaces are a grey area: RFC 4180 treats them as significant and does not require quoting for them, but because some tools trim unquoted whitespace, quoting a field whose spaces matter is the safe choice. Many CSV writers sidestep all of this by quoting every field unconditionally, which is always valid, if slightly larger. The minimal approach is to quote only when one of the three trigger characters is present.
How do you escape a double quote inside a field?
You escape a double quote by doubling it, writing two double-quote characters for each literal one, inside a field that is itself wrapped in quotes. This is the rule that surprises people, because there is no backslash escaping in CSV as there is in JSON or in most programming languages. Take the value She said "hi". To store it, the whole field is quoted, and each internal quote becomes two quotes:
She said "hi" (the raw value)
"She said ""hi""" (as written in the CSV file)Reading it back, a parser sees the opening quote that begins the field, then treats every pair of quotes as one literal quote, and treats the final lone quote as the end of the field. It looks strange the first time, but the logic is consistent: a doubled quote means a literal quote, and a single quote means a field boundary. Because the escape mechanism is doubling rather than a backslash, you cannot escape a comma or a newline this way; those characters are handled entirely by wrapping the field in quotes, not by escaping the character itself.
How are line breaks inside fields handled?
A newline can appear inside a field as long as that field is wrapped in double quotes, and it is then part of the data rather than a record separator. This is the single most important reason you cannot parse CSV by splitting the file on newlines. Consider a two-column file where the second column of one row contains a multi-line address:
name,address
web,"12 Main St
Suite 4"
api,"99 High St"This file has two data records, not three, even though it spans four physical lines. The newline between 12 Main St and Suite 4 is inside a quoted field, so it belongs to the address value. A parser that split on line breaks would wrongly see three rows and produce garbage. This is why real CSV parsing requires a state machine that tracks whether it is currently inside a quoted field: only line breaks encountered outside quotes end a record. The practical lesson is to never treat a CSV file as line-oriented text; always route it through a parser that understands quoting.
What line endings and headers does RFC 4180 expect?
RFC 4180 specifies that records are separated by a carriage return plus line feed, and it allows an optional header row as the first line, but real files vary on both points. The formal line ending in the RFC is CRLF, the Windows-style pair of a carriage return and a line feed. In practice, files produced on Unix-like systems frequently use a bare line feed, and most parsers accept either. This mismatch is a common source of a phantom trailing empty field or an extra blank row when a file crosses between operating systems. The header row is also optional in the spec: the first record may be column names or may be data, and there is no in-band marker to tell a parser which. Tools guess, remember a setting, or ask. When you generate CSV for others to consume, being explicit about whether a header is present, and choosing a line ending deliberately, avoids a whole category of interoperability confusion.
Why do CSV files still break between tools?
CSV files break between tools because CSV is a loose family of conventions rather than a single enforced format, so two programs can each be internally consistent yet disagree on the details. The main axes of disagreement are worth naming so you know what to check when a file imports wrong:
- Delimiter. The comma is only the default. Files from European locales often use a semicolon because the comma is the decimal separator there, and tab-separated files are common too.
- Line endings. CRLF versus LF, as covered above, causes stray rows and fields.
- Character encoding. UTF-8 is now usual, but files with a byte-order mark or in a legacy encoding produce mangled characters, especially a corrupted first column name.
- Quoting style. Some writers quote every field, some quote minimally, and a few use non-standard escaping, which trips parsers that expect the doubling rule.
- Header ambiguity. Whether the first row is data or column names is a guess unless the tools agree.
Because of this, the reliable way to move tabular data around is to convert through a well-defined format and inspect the result. Turning CSV into JSON makes the structure explicit, since every value becomes a clearly typed, quoted string in a named field, so you can see immediately whether quoting and delimiters were interpreted the way you expected. A client-side JSON and CSV converter does this in your browser without uploading the file, which matters because exported CSVs frequently contain personal data, customer records, or internal figures that should not be pasted into a remote service. Convert locally, look at the parsed output, and you catch a misread delimiter or a broken quote before it propagates.
CSV is deceptively simple: three characters, the comma, the double quote, and the line break, are all that require care, and the escaping rules for them are quote the field and double any internal quote. Learn those rules, remember that quoted fields can hold newlines so line-splitting is unsafe, stay alert to delimiter and encoding differences between tools, and verify by converting to a stricter format. That is the whole of RFC 4180 in practice.