table_view CSV ↔ JSON Converter star

How the Conversion Actually Works

CSV and JSON model data differently, and the direction you convert in determines how much guesswork is involved. CSV → JSON is close to mechanical: the header row becomes the set of keys, and every following row becomes one object with those keys — name,age over Ada,36 becomes [{"name":"Ada","age":"36"}]. Quoted fields containing commas, escaped quotes ("") and multi-line cells are parsed per RFC 4180, and the delimiter (comma, semicolon or tab) is detected automatically from the first line.

JSON → CSV is where the real difficulty lives. CSV is strictly flat — one row, one record, one value per cell — while JSON naturally supports nesting: an object can contain another object or an array as a field's value, and there's no universally agreed way to squeeze that into a single CSV cell. Take {"name":"Ada","address":{"city":"London"}} — should the column be named address.city (dot-notation, flattening the nested object into extra columns), or should the entire address value be embedded as a raw JSON string in one cell, like {"city":"London"}? Both approaches are used in the wild and neither is "the" standard; this tool takes the dot-notation route for one level of nesting and falls back to embedding JSON text for arrays and deeper structures, because that keeps simple objects genuinely spreadsheet-friendly without silently losing data on complex ones.

Worth internalizing: this isn't a gap in the tool, it's a gap in the data model itself. Any CSV↔JSON converter you try — this one included — has to make an editorial call about flattening, because the two formats were never designed to be perfectly interchangeable. CSV was built for tabular ledgers; JSON was built for arbitrarily shaped documents. Knowing that up front explains why round-tripping a complex JSON file through CSV and back rarely reproduces the exact original structure, and why keeping deeply nested data in JSON form is often simply the right call rather than a limitation to work around.

What's Worth Knowing

• CSV has no data types. Every value round-trips as text unless you enable number conversion, which turns numeric-looking strings into real JSON numbers (while leaving zero-padded IDs like "007" as strings, since converting those would corrupt them).
• The delimiter is auto-detected, not assumed. Excel exports with semicolons in many European and Turkish locales, because the comma is already the decimal separator there — the parser checks the header row to pick the right one.
• JSON → CSV unions all keys across objects. If some records have a field others don't, the header includes every key seen anywhere in the array, and missing ones are left blank in that row.
• Nothing leaves your browser. Parsing and conversion both happen locally in JavaScript, so pasting a sensitive export doesn't send it anywhere.
• Row order is preserved both ways. The first data row stays first after conversion in either direction, which matters when a spreadsheet or downstream script relies on positional order rather than an explicit sort key.