JSON and CSV are both ways of storing tabular data, but they think about structure differently. JSON is happy with nesting: an object can contain another object, and a field can hold a list. CSV is flat: rows and columns, nothing more. Converting from one to the other therefore involves decisions, not just reformatting, and the decisions are where conversions go wrong. A name containing a comma can split into two columns. A nested address can vanish or land in the wrong place. A missing field can shift every value after it one column to the left. The conversion is only correct when those cases are handled deliberately.

The JSON to CSV Converter performs that conversion in your browser. You paste in a JSON array of objects, and it produces CSV text with one row per object and one column per field. The tool's job is to make the structural decisions consistently: which columns exist, how values are quoted, and what happens to nested or missing data.

How the tool works

The first decision is the column list. The converter scans the objects — usually all of them, not just the first — and collects every field name it finds. That matters because JSON arrays do not guarantee uniform records: the first object might lack a field that the tenth object has. A converter that reads only the first record would drop that column entirely, silently losing data. A converter that scans everything builds the full column set, and records that lack a field get an empty cell in that column.

The second decision is quoting. CSV separates columns with commas, so any value that itself contains a comma, a line break, or a double quote must be wrapped in double quotes, and any double quote inside the value must be doubled. This is the rule that most hand-rolled conversions get wrong. A name such as Doe, Jane must appear as "Doe, Jane" in the CSV, or a spreadsheet will read it as two columns: Doe and Jane. A value containing a quote, such as Say "hello", must appear as "Say ""hello""". These rules are part of the CSV format itself, and a correct converter applies them to every value, not just the ones that look risky.

The third decision is nesting. A flat field maps directly to a column. A nested object needs flattening, typically into dotted column names such as address.city, or it needs to be serialised back into a JSON string inside a single cell. A list needs a similar choice: joined into one cell, or expanded into multiple rows. There is no single right answer, which is why you should inspect the output before importing it, especially for records with nested data. The converter's choice should be consistent across all rows, so that a column means the same thing in every row.

The conversion runs in your browser, so the data stays on your device. That is helpful when the JSON contains names, emails, or order details you would rather not upload to a remote service just to change its format.

A worked example

Take this JSON array of three customers. Every record has the same four flat fields, which keeps the example exact:

[
  { "id": 1, "name": "Ana", "city": "Leeds", "orders": 3 },
  { "id": 2, "name": "Ben", "city": "York", "orders": 0 },
  { "id": 3, "name": "Cara", "city": "Leeds", "orders": 5 }
]

The correct CSV output is:

id,name,city,orders
1,Ana,Leeds,3
2,Ben,York,0
3,Cara,Leeds,5

Four rows including the header, four columns in every row, and no quoting needed because no value contains a comma, a quote, or a line break. You can also verify the data survived the trip: add the orders column and 3 + 0 + 5 = 8 orders in total, matching the JSON. If the total changed after conversion, something went wrong — a row dropped, a value split, or a column shifted.

Now change one name to include a comma, and watch the quoting rule work. If the first record's name were Doe, Jane instead of Ana, the first data row must be:

1,"Doe, Jane",Leeds,3

Without the quotes, a spreadsheet would read five columns in that row — 1, Doe, Jane, Leeds, 3 — and the city and orders values would land in the wrong columns. With the quotes, the row still has exactly four fields. That single pair of quote characters is the difference between a clean import and a quietly corrupted spreadsheet, and it is exactly the kind of detail that is easy to miss when you convert by hand.

A final check before importing: open the CSV in a plain text editor, not just a spreadsheet. A spreadsheet hides quoting and may silently reinterpret values — turning a postcode-like string into a number, or a date-like string into a different date format. The text view shows you what the file actually contains, row by row, and any row with the wrong number of columns stands out immediately.

Common mistakes

The most common mistake is converting nested JSON without flattening it first. A record with an address object and a tags list cannot be represented as flat columns without a decision, and a naive converter may drop the nested data or dump it as unreadable text. If your JSON is nested, flatten the structure you care about — or use a table view to inspect it first — before converting, and confirm that the columns you need are present in the output.

The second mistake is ignoring missing fields. If some records lack a field, the converter must leave those cells empty, not shift later values left. A row with fewer columns than the header is a warning sign: either the converter dropped a value, or the record genuinely lacks that field. Count the columns in a few rows by eye, and compare the row count with the number of objects in the JSON. A mismatch in either direction means data was lost or duplicated.

The third mistake is opening the CSV in a spreadsheet and saving it again before checking it. Spreadsheets reinterpret values on import — leading zeros disappear from codes, long numbers become scientific notation, dates change format — and saving writes those reinterpretations back into the file. If you need to inspect the CSV, look at the text first, and only open it in a spreadsheet once you are confident the text is right.

The fourth mistake is assuming the conversion is reversible without loss. CSV cannot represent nesting, and it does not record types: the number 3 and the string "3" look identical in CSV. Converting JSON to CSV and back to JSON will not necessarily restore the original document. Treat CSV as a destination format for spreadsheets and imports, not as a round-trip storage format for structured data.

Honest limitations

A converter changes format; it does not clean, validate, or interpret your data. It will not tell you that a city name is misspelled, that an order count is implausible, or that two records describe the same customer. It also cannot preserve information that CSV cannot express: nested objects, lists with their structure intact, and the distinction between numbers, strings, and nulls. Null and empty string are another boundary — many converters write both as an empty cell, so a field that was explicitly null becomes indistinguishable from a field that was an empty string. If that distinction matters to you, handle it before conversion, not after. Finally, very large files may strain a browser-based converter; for those, converting in chunks or with a dedicated script may be more practical.

Closing

A correct JSON to CSV conversion is a matter of three checks: the full column set, correct quoting of tricky values, and a row count and spot total that match the source. Make those checks, inspect the text before importing, and the spreadsheet you produce will actually contain the data you started with. To go the other way, use the CSV to JSON Converter, and to inspect and tidy tabular data before or after conversion, use the CSV Viewer and Editor. For the wider skill of working with CSV files, see CSV to JSON Converter: Turn Rows Into Objects.