gizmobench

JSON to CSV

Paste an array of objects and the table appears beside it, with the three decisions that actually change the answer in front of you: whether a nested object becomes a dot path, an underscore path, a slash path or one cell of JSON, whether an array is written as JSON or joined into one cell, and which columns to write at all. The keys are unioned across every record, so a key one record does not have is an empty cell instead of a shifted row, and number literals are copied rather than re-printed, which is how a 20-digit id and a price of 1.50 come through intact. The same page runs the conversion backwards, and on that side nothing is retyped unless you ask: 007 stays "007" until you switch the types to Numbers.

output.csv

The CSV appears here, one row per record.

Nesting is yoursArrays stay in one cellBig numbers keptNothing uploaded
Direction
Nesting
Arrays
Delimiter
Header row

A nested object becomes one column per leaf key, joined with dot path, an array is written as JSON in a single cell, and a key a record does not have is an empty cell.

What happens to an awkward value

  • Nested object{"user":{"name":"Ava"}}
    id,user.name 1,Ava
  • Array value{"tags":["a","b"]}
    id,tags 1,"[""a"",""b""]"
  • Missing keyabsent on record 2
    id,email 1,a@b.c 2,

Common questions

How does a nested object become a column?
By its path. With the dot rule, {"user": {"name": "Ava"}} becomes a column called user.name holding Ava. Underscore and slash write the same path with user_name or user/name, which is what you want when a key already contains a dot. The fourth option leaves the object alone and writes it as JSON in a single cell, so {"name":"Ava"} arrives in the spreadsheet as text you can parse later. An object with no keys in it keeps its column and shows {}.
What happens to an array inside a record?
It stays in one cell. An array never turns one record into several rows, because that would quietly change how many records your file has. By default the array is written as JSON, so ["beta","paid"] appears as ["beta","paid"], quoted by the CSV rules. Switch the array rule to Joined and the same value becomes beta; paid, with strings as plain text and anything that is itself an object written as JSON.
My records do not all have the same keys. What then?
Every key that appears anywhere becomes a column, in the order the keys are first seen, and a record that lacks one gets an empty cell. Nothing shifts left, and no record is dropped for having a key the first record did not. The column list under the tool shows every column found, and switching one off leaves it out of the copy and the download.
Does it convert CSV back to JSON?
Yes, on the same page: switch the direction and the CSV pane opens with the type controls beside it. Fields are read by RFC 4180, so a quoted field may hold the delimiter, a line break and doubled quotes. Text, the default, keeps every field as a string. Smart reads true, false, null and plain numbers. Numbers also reads 007 as 7. The header row becomes the keys, so a column called user.name stays one key named user.name rather than being rebuilt into a nested object.
Will a long id or a leading zero survive?
Yes. The JSON is read by a parser that keeps every number as the literal text it was written as, so 12345678901234567890 reaches the CSV with all twenty digits and 1.50 does not become 1.5. Coming the other way, a zip code like 007 stays a string in Text and Smart, and only converts when you choose Numbers. A literal too large to hold as a number, such as 1e999, is kept as text rather than turned into Infinity.
Is anything uploaded?
No. The parsing, the conversion and the download all happen in the page, with no request to any server and no account. That matters here more than for most formats, because the arrays people convert are usually API responses, exports and customer records. You can paste up to 5,000,000 characters, 100,000 records and 2,000 columns in one pass, and anything larger is refused with the numbers rather than cut short.
What if the CSV or the JSON has a mistake in it?
The message names it. Invalid JSON is reported with a line, a column and a cause: a trailing comma, a single-quoted string, a Python True. On the CSV side, a row whose field count does not match the header is named by its row number with both counts, and a quoted field that never closes says which row it started on. Duplicate keys inside one record are legal JSON, so the conversion goes ahead and the note says which key was written twice.
Which delimiter does it use?
The one you choose: comma, semicolon, tab or vertical bar, in both directions. Whichever is in force, the output is quoted by RFC 4180, so a field containing the delimiter, a double quote or a line break is wrapped in double quotes and its own quotes are doubled. Reading CSV, if the first line holds more of another delimiter than the one selected, the tool says so rather than switching behind your back.

Exact conversion of the records you give it: every key that appears becomes a column, a missing key becomes an empty cell rather than a shifted row, and the CSV is quoted by RFC 4180. Reversing the direction converts types only where you say so.