Convert JSON to CSV

CSV is a habit, not a standard

RFC 4180 was published in 2005 and describes itself as informational. It documents what most people were already doing rather than telling anyone what to do, and plenty of software ignores it. That is why importing a CSV so often needs three attempts. The rules this tool follows are the RFC ones, because they are the closest thing to a common denominator:

• A field is wrapped in double quotes when it contains the delimiter, a double quote, a carriage return or a line feed.
• A double quote inside a quoted field is written twice. Alan "Turing" becomes "Alan ""Turing""". Backslash escaping is a different convention and most importers do not understand it.
• Rows end with CRLF, which is what the RFC asks for and what Excel is happiest with. Everything on Unix reads it fine.

Fields with leading or trailing spaces are quoted here too. The RFC does not require it, but a lot of parsers strip unquoted whitespace and you rarely want that.

Turning a tree into a rectangle

This is the part that cannot be done cleanly, only chosen. JSON nests; CSV does not. Three cases and what happens to each:

• A nested object is flattened into dotted columns, so {"address":{"city":"London"}} becomes a column called address.city. Turn flattening off and the whole object lands in one cell as JSON text.
• An array of values is written as JSON text in a single cell — ["maths","notes"] stays exactly that. Exploding it into tags.0, tags.1 would mean one row with forty tags adds forty columns to every other row.
• An array of objects, the one-to-many case, has no honest flat representation at all. Orders with line items, posts with comments: you either keep the JSON in a cell or repeat the parent fields once per child, and both are lossy in different directions. If you need the second, split the JSON into two tables and convert them separately.

Columns are the union of every key across every row, in first-seen order. A row missing a key gets an empty cell, which is why the row count and column count stay stable even when your objects are not.

The Excel problems

Three things go wrong between a correct CSV file and a correct spreadsheet, and none of them is the file's fault.

Encoding. Excel on Windows still reads a plain .csv using the system's legacy code page, so José arrives as José. A UTF-8 byte order mark at the start of the file tells it otherwise, which is why that checkbox exists and defaults to on. The BOM only goes into the downloaded file, never into the copied text, because everything else in the world treats it as junk.

Types. Opening a CSV by double-clicking it lets the spreadsheet guess. Leading zeros vanish, so the ZIP code 01234 becomes 1234. Long numeric IDs turn into scientific notation and lose their last digits. Anything shaped vaguely like a date becomes a date, in the locale's format. Use Data, then From Text/CSV, and set the awkward columns to Text during the import instead.

Formulas. A cell whose text begins with =, +, @ or a tab is evaluated as a formula rather than shown. That is CSV injection, and it is a genuine attack route when the data came from users. This tool counts those fields and warns you, but it does not neutralise them, because the usual fix — prefixing an apostrophe — corrupts the value for every non-spreadsheet consumer of the same file. Decide based on where the file is going.

What is missing

There is no streaming. The JSON, the parsed value and the finished CSV all sit in memory at once, so a few megabytes is comfortable and a hundred is not. Numbers are written the way JavaScript prints them, which means an integer beyond 2^53 has already lost precision before this tool sees it. And null and the empty string both come out as an empty cell — CSV has no way to tell them apart, so the distinction does not survive the trip.

Last updated September 19, 2026