JSON ↔ CSV Converter

Converts a JSON array of objects to CSV, or a CSV file back to JSON, with a real RFC 4180-style parser underneath — not a naive comma-split, which breaks the instant a value contains a comma, a quote, or a line break of its own.

Why "just split on commas" is the wrong approach

A value like "Smith, John" or He said "hello" inside a CSV field is exactly why the format has quoting rules in the first place: fields containing a comma, a quote, or a newline get wrapped in double quotes, and a literal quote inside a quoted field is escaped by doubling it (""). A parser that just splits on every comma breaks immediately on real-world data — addresses with commas, names with titles, any free-text field — which is a genuinely common source of "the CSV import silently produced garbage" bugs. This converter implements the actual quoting rules in both directions, so round-tripping data with commas, quotes and embedded newlines in it survives intact.

What happens to nested data going JSON → CSV

CSV is fundamentally flat — rows and columns, no nesting. If a JSON object has a nested object or array as a value, it gets serialized as a JSON string within that cell rather than silently dropped or flattened unpredictably. That's not a perfect fit for deeply nested data, but it's honest about what happened, and it's recoverable — JSON.parse() that cell's content back out if you need the structure again. If your data is genuinely nested and CSV is the wrong format for it, that mismatch shows up clearly rather than losing data silently.

What happens going CSV → JSON

Every value comes back as a string — CSV has no native concept of numbers, booleans, or null, just text. A column of ages becomes strings like "30", not the number 30. That's deliberate rather than a limitation: guessing at types (is "007" a number or a string that happens to look numeric? Is "NA" a string or supposed to be null?) is exactly the kind of silent, ambiguous behavior that causes bugs downstream. If you need typed values, convert them explicitly after import, with rules that match your actual data rather than a generic guess.

Where this actually gets used

Exporting API data or a database query result to a spreadsheet someone in another department needs to open in Excel, or the reverse — someone hands you a CSV export and your code needs it as JSON to actually work with. Both directions are common enough that having a converter that handles the edge cases correctly, rather than falling over on the first comma inside a quoted field, is worth more than it sounds.