JSON and CSV Converter

Getting API output into a spreadsheet

The usual reason to want this is that someone who does not read JSON needs to look at data that only exists as JSON. An endpoint returns an array of objects; a colleague wants it in Excel or Sheets. CSV is the lowest common denominator that every spreadsheet opens.

Nesting is the hard part

JSON is a tree and CSV is a rectangle, so something has to give. Nested objects are flattened into dotted column names — user.address.city becomes a column of exactly that name. The alternative, dumping raw JSON into a single cell, produces a file that is technically valid and useless to the person who asked for it.

Arrays of primitives are joined into one cell, since a variable number of columns per row is not a table. Arrays of objects genuinely cannot be flattened without either duplicating rows or losing structure, so those are reported rather than silently mangled.

Quoting is where converters silently corrupt data

RFC 4180 is short and widely half-implemented. A field containing the delimiter, a double quote, or a newline must be wrapped in double quotes, and any internal double quote must be doubled. Get it wrong and the failure is not an error — it is a row that quietly splits into two, usually discovered weeks later.

Both directions here follow the specification, including multi-line quoted fields when parsing back, which naive split(",") parsers always break on.

Ragged data is normal

Real API responses do not have identical keys on every object. The column set is the union of all keys across all rows, and missing values become empty cells rather than an error.

A note on Excel

Excel will interpret anything that looks like a number or a date. Leading zeros in a product code disappear, and a string like 1-2 may become a date. This is Excel's behaviour on import, not something the file can prevent — if it matters, import via Data → From Text and set the column type explicitly.