An API gave you JSON. A colleague wants it in Excel. Excel does have a JSON importer buried in Power Query, but it is fiddly and produces a nested structure that then has to be expanded column by column. CSV is the shorter path.
Converting
It runs in your browser, so API responses containing customer or user data are not sent to a third party.
What the input needs to look like
The conversion expects an array of objects — the shape most APIs return for a list:
[
{"id": 1, "name": "Ada", "signups": 3},
{"id": 2, "name": "Grace", "signups": 7}
]
Each object becomes a row, and the object keys become the column headers. That maps cleanly onto a spreadsheet.
If your JSON is a single object rather than an array, wrap it in square brackets to make it an array of one.
If your data is nested inside a wrapper — which is very common, since APIs like to return metadata alongside results:
{"status": "ok", "count": 2, "data": [ ... ]}
then extract the inner array first. Copy just the part inside "data" and convert that. Feeding the whole response gives you one row with a column containing the entire array as text, which is not what anyone wants.
The nested-object problem
This is where JSON and CSV genuinely do not agree, and no converter can fully solve it.
CSV is flat: rows and columns, one value per cell. JSON is a tree. When an object contains another object or an array, there is no single correct way to flatten it.
For example, a record where each user has a list of orders cannot become one row without either losing the orders or duplicating the user across several rows. Both are valid choices and both lose something.
Practical approaches:
Flatten before converting. Reshape the JSON into a flat array of objects, one per output row, using whatever language you have to hand. This gives you full control over the shape.
Convert nested parts separately. Export users as one CSV and orders as another, with a shared ID column. This is how the data would be stored relationally anyway, and it is often the right answer.
Accept the text. For a quick look, having a nested object land in a cell as JSON text is sometimes good enough — you can read it, even if you cannot sort by it.
Excel and CSV: three things that go wrong
Long numbers become scientific notation. A 16-digit order ID displays as 1.23457E+15 and, worse, Excel may round it. Import the CSV via Data → From Text/CSV and set that column to Text rather than double-clicking the file.
Leading zeros vanish. Postcodes, product codes and phone numbers lose them. Same fix: set the column type to Text on import.
Dates get reinterpreted. Excel is aggressive about recognising dates and will happily turn 03/04 into a date in whatever regional format it assumes. Import as Text if the values are not really dates.
All three come from double-clicking the file and letting Excel guess. Using the import dialog and setting column types takes an extra thirty seconds and avoids all of them.
Character encoding
If your data contains accented characters or non-Latin scripts, save the CSV as UTF-8 and open it via the import dialog, selecting UTF-8 as the encoding. Double-clicking a UTF-8 CSV in Excel on Windows often shows mangled characters, because Excel assumes the regional encoding rather than UTF-8. Google Sheets handles this correctly without intervention.