JSON to CSV Converter

JSON is a tree and CSV is a rectangle. That single mismatch explains everything about this conversion: a JSON object can nest to arbitrary depth and every record can have a different set of keys, while a CSV has one flat header row and every line must have the same number of fields. Making the tree fit the rectangle requires flattening, and flattening requires decisions.

The reason to do it anyway is that the rectangle is what other people can use. An analyst wants the data in Excel, a finance team wants to pivot it, a bulk-import tool wants a CSV upload, or you simply want to eyeball 400 API records without scrolling through 12,000 lines of JSON. This converter flattens nested objects into dotted column names, joins arrays into a single cell, and aligns records that do not all have the same keys. Everything runs in your browser.

How nesting is flattened

• Nested objects become dotted column names. {"plan": {"code": "team", "seats": 12}} produces the columns plan.code and plan.seats. Flattening recurses to any depth, so a three-level structure gives you a.b.c. This keeps the mapping reversible in your head and matches the path syntax used by jq and most config libraries.
• Arrays are joined into a single cell, with the items separated by a semicolon and a space. ["beta", "invoiced"] becomes the cell beta; invoiced. A semicolon is used rather than a comma so the value does not need quoting for the wrong reason and stays readable in a spreadsheet.
• Objects inside arrays are serialised as JSON into the cell, because there is no sensible way to spread a variable number of structured items across fixed columns. If your array of objects is the interesting data, extract it and convert that array on its own instead.
• An empty array becomes an empty cell.
• null becomes an empty cell, which means null and empty string look identical in the output. CSV has no way to distinguish them, and this is the most commonly overlooked lossy step in the whole conversion.
• Numbers and booleans are written literally — true, 29, 348 — with no quoting, because CSV has no types and every consumer will re-infer them anyway.

Ragged records and column order

Real API responses are rarely uniform. One customer has a referredBy field, another does not; one address has a postcode, another has only a city. A CSV cannot tolerate that, so the converter takes the union of every key across every record and uses it as the header row. Any record missing a key gets an empty cell in that column.

Column order follows first appearance: the keys of the first record in the order they appear, then any new keys contributed by the second record, and so on. That means the first object in your array effectively defines the layout. If you want a specific column order, put a record containing all the fields first — or reorder the columns in the spreadsheet, which is usually easier.

One consequence worth stating plainly: an empty cell is ambiguous. It might mean the key was absent, or present with a null value, or present with an empty string. If that distinction matters for your import, the flattened CSV is the wrong intermediate format and you should keep the JSON.

Quoting, and the things spreadsheets do to your data

The CSV itself is written to RFC 4180 rules. A field containing a comma, a double quote or a newline is wrapped in double quotes, and any double quote inside it is doubled. So Ferreira "Tom" Jr. is written as "Ferreira ""Tom"" Jr." and a note containing a line break stays inside one quoted field, spanning two physical lines. Any conforming parser reads it back correctly.

What happens after that is out of the converter's hands, and it is where data actually gets damaged. Opening a CSV in Excel triggers aggressive type inference: a postcode such as 049483 loses its leading zero and becomes 49483, a product code such as 1-2 becomes a date, a long numeric ID is displayed in scientific notation and silently rounded, and +44 20… may be treated as a formula. None of this is visible unless you look, and saving the file makes the damage permanent.

The defences are to use Excel's Data → From Text/CSV import path and set the problem columns to Text rather than double-clicking the file, or to import into Google Sheets with automatic detection disabled. If the CSV is being generated for a machine rather than a human, none of this applies — but check which case you are in before sending it to a colleague.

There is also a security angle: a cell whose value begins with =, +, - or @ can be interpreted as a formula by a spreadsheet, which is the basis of CSV injection. If your JSON contains untrusted user input and the CSV will be opened by someone else, sanitise those leading characters before distributing it.