JSON vs CSV is a shape argument. JSON holds typed nested objects and arrays. CSV holds rows that share a header. You can project an array of similar objects into CSV. You cannot project an arbitrary JSON document into a table without deciding which keys become columns and what happens to everything else.
Teams ask a converter to “just flatten it.” Flattening is a product decision: do you emit user.city columns, or do you leave user as a JSON string in one cell? Those are different files. This site does the second, on purpose, and says so.
CSV is right when a human will open a sheet, filter a column, or hand the file to someone who does not want braces. The input should be an array of objects with overlapping keys. The JSON to CSV Converter reads that array, builds a header from the union of keys, and writes one row per object. CSV with headers can come back to JSON as an array of objects.
A single object is not a table. A nested tree with no repeating records is not a table. Format that value with the JSON Formatter and keep it as JSON.
If a property is itself an object or array, the cell contains JSON text for that value. {"city":"Muscat"} in a address column is still nested data. Spreadsheet formulas will not see city as a column unless you flatten in another tool. That is the honest JSON vs CSV trade: you gained rows, you did not gain a relational schema.
Numbers, booleans, and nulls become cell text. Coming back to JSON, a converter has to decide whether "true" is a boolean or a string. Read the tool’s rule before you treat a round-trip as bit-identical.
The header is the union of keys. An object missing a key leaves an empty cell. An extra key on one object adds a column of empties for the others. That is not invalid CSV. It is a sparse table.
Commas, quotes, and newlines inside cells must be escaped. A converter that does not quote those cells produces a file that is not CSV, even if it opened once in a lenient editor.
One JSON object per line is still JSON. It is a good log shape. It is not a spreadsheet. See JSON vs JSON Lines. The JSON Lines to JSON page will turn those lines into an array. From that array you can export CSV if the objects are flat enough. Skipping the array step and renaming .jsonl to .csv does not create columns.
Use JSON when the data is a tree. Use CSV when the consumer is a table and you accept nested leftovers as text. JSON vs CSV is not solved by a wider header. It is solved by saying which keys are columns and which values stay JSON in a cell.
Excel and Google Sheets will split on commas they should not if the exporter forgot quotes. Always open a sample row that contains a comma inside a string. If that row becomes two columns, the file is wrong before anyone talks about nested JSON.
A second export from the same API may add a key. The new header is wider. Diffing two CSV files then looks like every row changed because columns shifted. If you need a stable table, lock the header in your own script. A union-of-keys export will not do that for you.
Keep the JSON fixture next to the CSV. When a cell looks empty, check whether the object lacked the key or whether the value was null. Those are different JSON facts and often the same blank cell. JSON vs CSV loses that distinction unless you document it.
The converter kept it as JSON text in one cell. That is not a full flatten. Split columns in another step if you need them.
Not usefully. You need an array of objects, or CSV with headers going the other way. A lone nested object is still a tree.
No. JSON Lines is one JSON value per line. CSV is headers and rows. Convert lines to an array first if you want a sheet.
Only if the converter documents how it reads cell text. Do not assume "true" becomes a boolean unless the page says so.
