JSON to CSV
Turn a JSON array of objects into a CSV table ready for Excel or Google Sheets. Columns are detected automatically from your keys and nested values are kept
Turn an array of JSON objects into a CSV table that Excel, Google Sheets, Numbers and LibreOffice open with the columns already separated. Column names come from the object keys, and the union of all keys is used, so rows with missing fields still line up correctly.
This is the standard step when an API returns data you want to sort, filter or chart: fetch the JSON, paste it here and the spreadsheet is ready. Values that are themselves objects or arrays are kept as JSON text inside the cell, so no data is silently lost.
How to convert JSON to CSV
Paste a JSON array of objects
Check the detected columns
Copy or download the CSV
FAQ
What JSON shape does it expect?
An array of objects, such as [{"name":"Ana","age":31}, ...]. A single object is treated as one row; deeply nested structures are flattened into JSON text within the cell.
How are column names chosen?
From the keys of the objects. All keys that appear anywhere in the array become columns, and missing values are left empty.
Are commas and quotes in my data safe?
Yes, values containing commas, quotes or line breaks are quoted and escaped according to the CSV standard, so the file opens with the right number of columns.
Why does Excel show everything in one column?
Excel may guess the wrong delimiter when opening a .csv directly. Use Data > From Text/CSV and choose the comma delimiter, or save the file as .xlsx instead.
What happens to nested objects?
They are written as JSON text inside the cell rather than being expanded into columns, so the original structure is preserved and can be parsed again later.
Is my data uploaded?
No, the conversion runs in your browser - important when the JSON contains customer records.
At a glance
| Input | JSON |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.