What the converter does
This JSON to CSV converter turns an array of objects into a spreadsheet-shaped file, in your browser, following RFC 4180 rather than joining values with a comma and hoping. Nested objects are flattened to dotted paths, arrays become either a single JSON cell or one column per index, and the header is the union of every key across every object, in the order the keys first appear.
A single object works too — it becomes a file with one data row. What will not work is an array of strings or numbers, and the tool says so instead of inventing a column name for you.
Quoting is the whole specification
CSV looks trivial until a value contains the delimiter. RFC 4180 has exactly one answer: wrap the
field in double quotes, and double any quote already inside it. A field holding Ada, Countess
becomes "Ada, Countess", and He said "hi" becomes "He said ""hi""".
The same rule covers line breaks. A multi-line note stays in one cell as long as it is quoted, and every conforming reader will keep it there. This is why hand-rolled exports break: they escape the comma, forget the newline, and the file grows a phantom row that nothing downstream notices until a month-end report is wrong.
Fields that need none of that are left alone. Quoting every cell would also be valid, and it would make the file unreadable for the human who opens it — which is usually the reason CSV was chosen.
Why Excel wants a semicolon and a BOM
Excel is the destination for most of these files, and it is opinionated in two ways that have nothing to do with the format.
First, the separator. When you double-click a .csv, Excel does not inspect the file. It splits on
the list separator configured in Windows, which is a semicolon in Germany, France, Spain, Italy,
Brazil and much of the rest of the world, because those locales use the comma as a decimal mark. A
perfectly valid comma-separated file therefore arrives as a single column, and the person who
receives it concludes the export is broken.
Second, the encoding. Excel on Windows assumes a legacy code page unless the file starts with a
UTF-8 byte order mark. Add it and Müller survives; skip it and you get Müller. The toggle exists
because the BOM helps a human and hurts a script — a naive parser will read the marker as part of
the first header name.
If you control both ends, the durable fix is neither of those. Import through Data, then From Text/CSV, and Excel asks about the delimiter and the encoding explicitly, ignoring the machine settings entirely.
Nesting, and what a flat file cannot hold
JSON is a tree; CSV is a grid. Flattening to address.city is lossless for objects, and the dotted
name survives a round trip well enough that most tools can rebuild the structure.
Arrays are different, and neither answer is right for every case. One cell containing the raw JSON keeps the data intact and keeps the column count stable, which matters if the file feeds a database load. One column per index is readable and sortable in a spreadsheet, but the column count now depends on the longest array in the batch, so today's export and tomorrow's may not have the same shape. Pick the first for machines and the second for people.
Numbers that are not numbers
The most common complaint after an export is a column that lost data, and it is almost never the
export. Leading zeros in postcodes and account codes disappear because a spreadsheet reads the
column as numeric. Long identifiers such as credit card or IMEI numbers lose their last digits to
floating point. A value like 1-2 can be reinterpreted as a date, and SEP1 as something stranger.
The CSV in the box is correct in every one of those cases; the damage happens at import. The fix is always to declare the column as text before loading, never to change the file.
When you need the trip in the other direction, the CSV to JSON converter parses the same quoting rules back into objects. For a table meant to be read in a pull request or a README rather than a spreadsheet, the Markdown table generator takes the same pasted rows and gives you aligned pipes instead.