CSV File: What It Is and What the Format Leaves Open

What is a CSV file?

A CSV file is a plain-text file that stores a table as records, one record per line, with a comma between one field and the next.

CSV stands for comma-separated values. The first line may name the columns, and every line after it is one record, its fields in the same order as those names. Here is a small file, line by line.

The second record is why quoting exists. The comma inside "Bolt, M6" belongs to the value, so the field is wrapped in double quotes and the line still splits into three fields rather than four.

RFC 4180 registers the text/csv media type and names CSV as its file extension, but gives the format no signature bytes, so nothing inside the file marks it as CSV.

So the label sits outside the file: its name, or the media type it was sent with. A program that has neither has to guess from the contents.

Is there a standard for CSV files?

Partly. RFC 4180 writes down the rules most programs follow, but it describes common practice rather than setting a standard, and it says so.

RFC 4180 is Informational and says plainly that no single master specification for CSV exists. The header line is optional and is signalled outside the file by the text/csv header parameter, and the document warns that some implementations use line endings other than CRLF.

RFC 4180 fixes four things for CSV: each record sits on its own line ending in CRLF, fields are separated by commas, a field holding a comma, a double quote or a line break is wrapped in double quotes, and a double quote inside a quoted field is written twice.

You can convert a CSV file to JSON and see the converter apply all four rules, with the decision it took about every field listed beside the result.

RFC 4180 carries the character set as an optional text/csv parameter and names US-ASCII as common usage. Nothing inside a CSV file records its encoding, so the encoding has to be known before the file is read.

Put the rows together and a CSV file cannot tell you three things: which encoding it was saved in, whether its first line is data, or what type any value is. A converter has to be told, or has to guess and say that it guessed.

Semicolons, tabs and other CSV dialects

A semicolon-separated or tab-separated file is not RFC 4180 CSV. The grammar fixes the separator at the comma (%x2C) and the media type has no delimiter parameter, so any other separator is read by convention rather than by the specification.

A reader that accepted only the RFC form would refuse such files outright. The converters here take the other route and label what they did.

The converters on this site read three dialects of delimited text: comma-separated as RFC 4180 writes it, semicolon-separated and tab-separated. A file split on anything but the comma is reported as read by convention.

The same reader accepts lines that end in LF alone, removes a byte order mark from the front of the file and skips a blank line between records, and it reports all three. It refuses a double quote inside a field that did not open with one.

That last refusal is deliberate. Without the opening quote there is no telling whether the quote mark is part of the value or a mistake, and a guess would move every later value into the wrong column.

A TSV file's first line is the field names, and the IANA registration puts that line in the grammar as tsv ::= nameline record+. Where CSV's header row is optional, a TSV file without a name line is not TSV.

A file with tabs throughout is TSV rather than CSV with another delimiter. To read a tab-separated file into JSON, use the converter built for those rules.

What is the difference between CSV and JSON?

CSV is a flat table of text, and JSON is a tree of typed values. A CSV record is a line that the header names once; a JSON object names every value it holds, and can hold further objects and arrays inside it.

RFC 8259 gives JSON four primitive types - string, number, boolean and null - and two structured types, object and array. There is no date type and no separate integer type, so a date arrives as a string and every number is read the same way.

Converted, the sample file above shows both halves of that difference:

The file sku,item,qty / A-10,"Bolt, M6",25 / B-20,Washer,100 becomes [{"sku":"A-10","item":"Bolt, M6","qty":"25"},{"sku":"B-20","item":"Washer","qty":"100"}] when every field is read as text.

Those 49 bytes of CSV become 88 bytes of JSON, because every object repeats the column names that the header line wrote once.

Three things happened on the way. The header line was used up as keys, the quoted comma stayed inside its value, and 25 arrived as the string "25", because nothing in the file said it was a number. Nothing was lost on this file.

The trip back is where a table runs out of room. To write JSON back out as CSV rows, the converter writes CSV with one row per array element, nested objects flattened into dotted column names, and an empty cell where a key is missing.

Neither format is better in general. A flat table of text is what CSV was made for; data with nesting, numbers that must stay numbers, or a null needs JSON.