JSON to CSV Converter

Most exports from APIs come back as JSON, but most stakeholders open spreadsheets, so the conversion happens constantly with mixed-quality results.

Paste a JSON array of objects (the most common shape for tabular data) and get a CSV. Nested objects are flattened with dot notation (user.address.city becomes a column header), arrays of primitives become semicolon-separated strings, arrays of objects can be either flattened-with-prefix or kept as JSON strings (configurable per situation).

Quoting follows RFC 4180: fields containing commas, quotes, or newlines get wrapped in double quotes, with internal quotes escaped by doubling. Excel-friendly variants are also offered, including the BOM prefix for UTF-8 (so Excel doesn't mangle non-ASCII characters when opening the file). Headers come from the keys in the first object — irregular schemas across rows get unioned into a complete header set.

The conversion walks the JSON array, collects keys from all objects (a union, not an intersection — irregular schemas across rows still produce complete headers), and writes one row per object. Nested objects are flattened with dot notation by default. Arrays of primitives become semicolon-joined strings. Arrays of objects can be flattened with index suffixes (items.0.name, items.1.name) or kept as JSON strings, depending on the configuration. The output follows RFC 4180 quoting: any field containing commas, double quotes, or newlines gets wrapped in double quotes, with internal quotes doubled.

The pain this addresses: a stakeholder asks for 'the data as a spreadsheet' and you have it as a JSON API response. Excel doesn't open JSON. Google Sheets has limited support. Most analyst-friendly tools speak CSV. Doing the conversion by hand for a 500-row dataset means writing a one-off script, getting the quoting wrong, watching cells split where they shouldn't, fixing it, regenerating. The converter handles RFC 4180 correctly the first time and includes the BOM prefix that Excel needs for UTF-8 files (otherwise non-ASCII characters render as garbage in Excel).

Worked example: input is `[{"name":"Alice","address":{"city":"NYC","zip":"10001"}},{"name":"Bob","address":{"city":"LA"}}]`. Output: ``` name,address.city,address.zip Alice,NYC,10001 Bob,LA, ``` The nested address object flattens to two columns (address.city and address.zip). Bob's missing zip field becomes an empty cell, which is the right behavior — JSON doesn't require every object to have the same keys, and CSV represents missing values as empty strings.

Where flattening can mislead: deeply nested data with arrays of arrays. JSON like `[{"items": [["a","b"],["c","d"]]}]` doesn't have a clean tabular form. Either you flatten it into many columns (items.0.0, items.0.1, items.1.0, items.1.1) which gets unwieldy fast, or you keep arrays as JSON strings in single cells, which means downstream tools have to re-parse them. Neither is great. If your data is genuinely hierarchical, CSV is the wrong format — consider Parquet or keeping it as JSON and using a tool that handles nested data directly (DuckDB, BigQuery, jq).