Convert JSON to CSV

This is the one thing to understand before converting anything. JSON describes a tree: an object can hold another object, which can hold an array of objects, to any depth. A CSV describes a grid: rows and columns, and nothing inside a cell.

So the conversion is not a translation between two ways of writing the same thing. It is a projection, and something has to give. For data that is genuinely a list of flat records — which most exports are — nothing is lost at all. For anything deeply structured, the CSV is a readable approximation and the JSON remains the real file.

A nested object is flattened by joining the key names, so a record with a customer containing a city produces a column named for both. One level of nesting produces a table anybody can read. Two is usually still fine.

Beyond that it degrades quickly: column names become long, the table 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 showing through rather than a fault in the conversion.

A record with three tags, four line items or a list of previous addresses has no correct representation in a table. There are three usual answers and each is wrong for something: one column per position, which breaks when a record has five; one column with the values joined by a separator, which is unparseable if the values contain that separator; or one row per array element, which duplicates the parent record and changes what a row means.

When arrays carry the meaning — an order with line items, a post with comments — the honest answer is not to convert. Either keep the JSON, or produce two tables the way a database would: one for orders and one for line items, joined by an identifier.

Records in a JSON export are not obliged to have the same keys. An API returns fields that exist and omits ones that do not, so a hundred records can present eighty different shapes.

The conversion resolves that by looking across the records to build the full set of columns and leaving a cell empty where a record has no value. This is normally what you want, and it explains a common surprise: converting a ten-record sample produces fewer columns than converting the whole file, because the sample simply did not contain the rarer fields.

Producing a correct CSV does not protect it from what happens next. Excel opens one by guessing a type per column, which strips leading zeros from codes, converts anything date-shaped into a date, and truncates identifiers past fifteen digits.

The remedy is the same as always: import rather than open — Data, then From Text/CSV — and set the identifier columns to Text before loading. If the recipient is a person rather than a program, converting to XLSX instead removes the guessing altogether, because the types are declared in the file.

Convert when the data is flat records and the destination is a spreadsheet, a database import, a statistical tool or a colleague. That covers most exports from analytics platforms, CRMs, form builders and reporting APIs, and the CSV is easier for every one of those than the JSON was.

Do not convert when the structure is the content — a configuration file, a nested API response you intend to work with programmatically, anything with meaningful arrays. And keep the JSON either way: it is the file that still contains everything, and regenerating a CSV from it takes seconds.

Data exports from AI services are now one of the most common reasons anyone opens a JSON file, and the ChatGPT archive is the usual one. Its `conversations.json` is not a list of rows: it is a set of message trees, each node pointing at its parent, which is how branched and edited conversations are represented. There is no honest grid inside it.

Converting it to CSV produces something technically valid and practically unusable — one row per node, with the thread structure gone. If the goal is to read your conversations, the exported HTML file in the same archive is what to open. CSV is the right target for the flatter exports beside it, such as usage and billing records, where each entry genuinely is a row.

A JSON array has to be complete before it can be parsed, because the closing bracket is what makes it valid. So a very large file has to be read whole, and that is a property of the format rather than of any particular tool.

If you control how the data is produced, ask for NDJSON — one complete JSON object per line — instead of one large array. It still has to be read into memory whole here, the same as an array does, but each line is parsed on its own: a corrupted or truncated line fails with its own line number instead of invalidating the entire document. It is what log pipelines and large data exports use for exactly this reason, and every tool that reads JSON reads it with a one-line change.

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

That is worth more here than on most conversions. A JSON export is nearly always the raw output of an API — customer records, order histories, form submissions, user accounts — and it usually contains fields nobody thought about because nobody was expected to read them. Not sending it anywhere is the simple answer.