CSV RFC 4180 Rules
RFC 4180 defines CSV precisely: records separated by CRLF, fields separated by commas, and double quotes around any field containing a comma, quote or line break — with embedded quotes doubled as "". The header row is optional, the delimiter is a comma, and the MIME type is text/csv. Most real files follow it loosely.
Die folgende Anleitung ist nur auf Englisch verfügbar.
CSV RFC 4180 Rules explained
CSV is older than its specification. Files of comma-separated values had been exchanged for decades when RFC 4180 was published in October 2005 as an informational document — not a new design, but a careful description of what the world already did, written down so parsers could agree. That origin explains both its brevity and its most common criticism: the standard describes the convention, and the convention predates the standard.
The rules themselves are short. A file is a sequence of records; records are separated by CRLF; fields are separated by commas; and a field containing a comma, a double quote or a line break must be enclosed in double quotes, with internal quotes written doubled. Everything else — encodings, headers, ragged rows — the RFC either makes optional or leaves to practice, which is why real-world files drift.
This guide walks the grammar rule by rule with copyable examples, marks the places where the spec says 'may', and catalogs the divergences you will actually meet: byte order marks, semicolon delimiters, Unix line endings. The converters linked throughout implement the full grammar — quoted fields, embedded newlines and all — entirely in your browser.
A grammar is easiest to see from a parser's output: paste a quoting-heavy file into the CSV to JSON converter and each rule above becomes a field in the JSON it builds — parsed locally, nothing uploaded.
On the producing side, the JSON to CSV converter quotes exactly where RFC 4180 requires, so round-trips through spreadsheets survive commas and newlines in your data.
The grammar: records, fields, CRLF
RFC 4180's grammar fits in a paragraph. A file consists of records, each record a sequence of fields separated by commas; records are separated by CRLF — the two bytes 0x0D 0x0A, not the bare LF of Unix tooling — and the last record may or may not end with a trailing CRLF. Fields may or may not be quoted: quoting is conditional, not a style. The ABNF sketch is file = [header CRLF] record *(CRLF record); record = field *(comma field) — note the optional header inside the brackets.
A minimal compliant file
id,name,score 1,Ada,99 2,Grace,98
The same file as records
record 1: id=1, name=Ada, score=99 record 2: id=2, name=Grace, score=98 (each record ends with the two bytes CRLF; the last one may legally omit them)
Quoting: the double quote is the whole escape system
A field is wrapped in double quotes when it must be, and the only way to put a double quote inside a quoted field is to double it — "" inside a quoted field means one literal quote. That is the entire escaping mechanism: no backslashes, no named entities, no second quoting character. Single quotes are ordinary data, and a stray space after a comma is part of the next field — the spec is explicit that spaces are preserved and must not be trimmed.
| The value you want | The RFC 4180 field | Why |
|---|---|---|
| plain | plain | Quotes optional — bare form is the default |
| with, comma | "with, comma" | Fields containing commas must be quoted |
| with " quote | "with "" quote" | Embedded quotes are doubled inside quotes |
| with newline | "with newline" | Quoted fields may contain line breaks |
| padded | padded | Spaces are data — quoting optional, trimming forbidden |
One record, every quoting rule at once
year,quote,note 1962,"she said ""look, no hands""","multi-word, no problem"
Parsed fields
year → 1962 quote → she said "look, no hands" note → multi-word, no problem
Newlines and commas inside fields
Because quoted fields may contain line breaks, a CSV line is not a record: a naive splitter on \n corrupts any file with multi-line fields — which is why address blocks, notes columns and JSON-in-CSV payloads break naive importers. A conforming parser is a small state machine: inside quotes, commas and newlines are data; outside, they are separators. It cannot be written correctly with split() alone.
The same state machine settles the double-quote edge cases: a quote opening mid-value, an unterminated quote at end of file, doubled quotes at the very end of a field. These are exactly the cases RFC 4180's few rules were written to settle, and exactly where hand-rolled parsers disagree with one another — the source of most 'works in Excel, breaks in the importer' reports.
Two records, three physical lines
name,address "Ada","12 St James Square, London" "Grace","1 Loop Rd"
What a conforming parser yields
record 1: Ada | 12 St James Square, London record 2: Grace | 1 Loop Rd (the comma inside the address is data; so is the CRLF inside the quotes)
CRLF, the optional header, and text/csv
Three details are fixed by the spec and routinely assumed otherwise. Records end with CRLF — though the final record may omit it, and every parser you use daily accepts bare LF. The first record may contain column names, but the grammar treats it as optional: a header is a convention the format supports, not a structure it requires, which is why tooling must be told — or must guess — whether row one is data. And the registered MIME type is text/csv — registered by RFC 4180 itself — with charset parameters left to the sender.
One more boundary the RFC draws firmly: the delimiter is the comma. Semicolon-separated files are a spreadsheet locale convention — common wherever the decimal comma is standard — not a variant the standard recognises. A compliant writer never guesses, and a compliant parser either sniffs the delimiter or is told, but the file itself carries no marker of which convention it follows.
Where real files drift from the standard
Real CSV predates the RFC, so divergence is the norm rather than the exception. Five drifts account for nearly every 'this CSV won't parse' incident:
Good tools surface these deviations instead of silently guessing. When a file matters — invoices, financial imports, anything a regulator may read — compare it against the grammar above and fix the drift at the source, rather than teaching every downstream parser the same exception.
| Drift | Typical source | What breaks |
|---|---|---|
| UTF-8 BOM before the header | Spreadsheet 'CSV UTF-8' exports | First column name gains three invisible bytes |
| LF-only or mixed line endings | Unix tooling; hand-edited files | Strict CRLF splitters misread record boundaries |
| Semicolon or tab delimiter | Non-English spreadsheet locales | Comma-only parsers merge columns |
| Inconsistent quoting | Partial exports; manual edits | Parsers assuming uniform quoting misread values |
| Ragged rows | Manual edits; careless joins | Field-count assumptions; column drift downstream |
Writing CSV that survives round-trips
The dependable producer's checklist follows directly from the grammar: quote uniformly — every field, or exactly the fields the rules require; both are compliant, but uniform is safer to read back — emit CRLF, write the header row, and encode UTF-8, accepting that a BOM is sometimes the price of a spreadsheet's recognition. Round-trip anything important: parse the file you just wrote, confirm every field matches the source data, then ship it. The recurring failure mode is always the same — a value containing the delimiter that the writer never quoted.
Frequently asked questions
Is my CSV uploaded when I use the converters linked here?
No — the CSV to JSON and JSON to CSV tools on this site parse and emit entirely in your browser: there is no upload step, no server-side copy, and the Network panel stays empty while they run. The site's Content-Security-Policy also blocks outbound connections, so customer data pasted from a spreadsheet cannot leave the tab.
Is the header row required in a CSV file?
Not by the standard: RFC 4180's grammar makes the first record optional, exactly like any other record — a header is a convention it permits, not a structure it mandates. In practice consumers differ: database importers often ask you to declare whether the first row is data or names, while spreadsheet tools simply assume a header exists.
Why does my CSV file use semicolons instead of commas?
That is a spreadsheet locale convention, not a different standard: locales that use the comma as a decimal separator adopted the semicolon so numbers like 3,14 do not collide with field separators. RFC 4180 fixes the delimiter as the comma, so tools must sniff the file, offer a configuration option — or misparse, which is why an export can open fine locally and break downstream.
How do you put a quote character inside a CSV field?
Double it, inside a quoted field: the value say "hi" becomes "say ""hi""" in the file — the interior quote doubles to a pair, and where the doubled pair meets the closing quote you get three in a row. Doubling is the format's only escape mechanism — no backslashes, no entities. An unquoted field cannot legally contain a quote at all, and parsers disagree on forgiving that, so the portable form always quotes the field and doubles its interior quotes.
Why does one CSV record sometimes span several lines?
Because quoted fields may contain line breaks, records and physical lines are different things. A three-line address in one field makes a single record span three lines, and any splitter that treats \n as a record boundary corrupts the file from there on. Conforming parsers track whether they are inside quotes — a small state machine, not split().
What line endings does CSV actually require?
RFC 4180 specifies CRLF between records — both bytes, 0x0D 0x0A — with the final record allowed to omit them. The real world is looser: Unix tools emit bare LF, mixed endings appear in hand-edited files, and most parsers accept all three. Writers that must interoperate with spreadsheets should emit CRLF; readers should tolerate the rest.
Which related tools should I use next?
- CSV to JSONParse a spreadsheet export into records, quoting and all.Open
- JSON to CSVConvert records to a spreadsheet grid, nesting and all.Open
- What Is JSONPlain-English guideOpen
- JSON Syntax Cheat SheetPlain-English guideOpen
- JSON ToolsCompare, format, validate and explore JSON documents.Open
- JSON ValidatorValidate syntax with exact line and column, and repair it in one click.Open