Convert JSON to XLSX

That is the whole distinction from converting to CSV, and it decides everything else. A program wants CSV: it streams, every import routine reads it, and it carries no formatting to get in the way. A person wants a workbook that opens with the columns the right width, the headers already a header row, and the types already correct.

If the data is going into a database, a script or an analysis pipeline, CSV is the better answer and this is the wrong page. If it is going to a colleague who will look at it, sort it and add a column, this is the one.

A CSV has no types at all. Excel opens one by guessing a type for every column, and that guess is where the familiar damage happens: leading zeros vanish from postcodes and product codes, anything date-shaped becomes a date, and identifiers past fifteen digits lose their last digits to floating point.

An XLSX declares what each cell is, so nothing is inferred and nothing is rewritten on opening. That single difference removes an entire category of support conversation, and it is the reason to spend the extra step rather than sending a CSV and an explanation.

Each record becomes a row and each key becomes a column, with the header row taken from the keys themselves. Records that do not all share the same keys are reconciled by building the full set of columns across the file and leaving empty cells where a record has nothing to put.

That reconciliation is worth knowing about because it explains a common surprise. Converting ten records for a test can produce a narrower sheet than converting the whole export, simply because the sample did not happen to contain the rarer fields.

JSON describes a tree and a spreadsheet is a grid, so a nested object is flattened by joining the key names into the column heading. One level produces a sheet anybody can read; two is usually still fine.

Beyond that it degrades in a way that is obvious the moment you look at it: headings become long, the sheet becomes very wide, and most cells in most rows are empty because different records nest differently. If a conversion produces sixty columns from what looked like a simple export, that is the shape of the data rather than a fault — and a signal that the JSON should probably stay JSON.

An order with five line items, a post with a list of tags, a person with several previous addresses — none of these has a correct single-row representation. The three available answers are one column per position, one column with the values joined, or one row per element, and each breaks something.

When arrays carry the meaning, do what a database would: produce one sheet for the parent records and one for the children, joined by an identifier. It is more work than a single conversion and it is the only version a spreadsheet user can actually reason about.

The archive that ChatGPT, Claude or an API dashboard hands over is JSON because that is what a machine reads, and most people receiving one have no tool that opens it usefully. A spreadsheet is the realistic answer: XLSX declares its types, so timestamps stay timestamps and long numeric IDs are not silently rewritten in scientific notation the way a CSV opened in Excel would rewrite them.

It works well for the flat parts — usage logs, billing lines, message lists with one entry per row. It works badly for the conversation archive itself, which is a tree of message nodes rather than a table, and flattening it produces columns named after paths nobody wants to read. Convert the part you actually need rather than the whole export.

Look at the sheet, briefly. Two things are worth checking every time: that the identifier columns read as text rather than having been formatted into numbers, and that the date columns look like dates rather than like five-digit numbers.

And check what is actually in it. A JSON export from an API contains every field the API returns, including internal identifiers, flags and occasionally fields nobody realised were there. A spreadsheet makes all of it visible in a way a JSON file does not, which is a good thing to discover before the file leaves your organisation rather than after.

The conversion runs in the browser tab on your own processor. The file is never sent anywhere, there is no account and no daily allowance, and the limit is 100 MB a file.

That is more relevant here than on most conversions. A JSON export is nearly always the raw output of a system — customer records, orders, form submissions, user accounts — and handing it to a third-party converter means handing over exactly the data an organisation is answerable for. Not sending it anywhere is the simplest form of not having to trust anybody with it.