JSON ⇄ CSV Converter

Flatten first, and there are two shapes to choose between. If the nested part is a single object — an address, a block of metadata — give each leaf its own column with a joined name, address_city and address_postcode, so one row still means one record. If it is an array of children, such as line items on an order, one table cannot hold it honestly: either write a second CSV with one row per child and an order id pointing back, or accept a lossy summary like joining tags into a single cell with a semicolon. Choose before you convert, because the right answer depends on what the spreadsheet is for.

Because Excel splits on whatever your locale calls the list separator, and across much of Europe that is a semicolon. A comma-separated file opened by double-clicking on such a machine lands entirely in column A. The fix is not to double-click: use Data, then From Text/CSV, and set the delimiter and the encoding yourself in the import dialogue. Google Sheets asks the same question under File, Import. The other direction matters here too — a semicolon-separated export pasted in for conversion comes back as one field per row, because a comma is the only separator this reader recognises.

Because a CSV carries no types, so the spreadsheet guesses, and its guesses are aggressive. Leading zeros vanish from postcodes and product codes. An identifier past fifteen digits is shown in scientific notation and the trailing digits are genuinely lost rather than merely hidden. Anything resembling a date is rewritten as one. None of that is in the file — it happens as Excel reads it, which is why the same file looks correct in a text editor. Import through Data, From Text/CSV and mark those columns as Text, or keep the JSON as your source of truth and treat the CSV as a view of it.

Wrap the whole field in quotation marks. Inside them a comma is just a comma and a line break belongs to the value rather than starting a new row. A quotation mark inside the field is written twice rather than escaped with a backslash, which is the rule most people get wrong, since backslash escaping is not part of the format at all. Those conventions come from RFC 4180, the nearest thing CSV has to a specification, and they are what this converter implements in both directions. Quotes are added only where a field needs them, so ordinary values stay unquoted and the output stays readable.

Here, nowhere. Both conversions are plain JavaScript functions running in the page you already have open, recomputed as the text in the box changes. There is no upload, no download and no request to a server, and the text lives only in the page's own state, so closing or refreshing the tab clears it. That matters for this job in particular, since what people paste into a JSON to CSV box is usually a customer export or an order list. With converters generally, the questions worth asking are whether the file is sent somewhere to be processed and how long it is kept.

You add them back deliberately, because the file genuinely does not contain them. Cast the fields you know: Number on the numeric ones, an explicit comparison against the word true for booleans, a date parser where a column really does hold dates. Resist a blanket auto-detect that converts anything number-shaped — that is what quietly destroys phone numbers with leading zeros, version strings like 1.10, and identifiers long enough to lose precision. Blank cells are the other ambiguity: an empty field could mean an empty string, a null, or a key that was never there, and only you know which.

Not as it stands. One object per line is JSON Lines, also called NDJSON: a stack of separate documents rather than a single one, which is exactly what makes it good for streaming and for appending to a log. A parser expecting one array rejects it with a syntax error. Converting is mechanical — put a comma at the end of every line but the last and wrap the lot in square brackets, which jq -s does in one step. Going the other way, take your array, drop the outer brackets and put each object on its own line with no trailing commas.

UTF-8, in nearly every case: it covers accented names and non-Latin scripts, and JSON is assumed to be UTF-8 already. The complication is Excel on Windows, which historically read a plain UTF-8 file using the local code page and turned accented characters into mojibake unless the file opened with a byte-order mark — three invisible bytes announcing the encoding. That mark then causes trouble of its own, because many parsers, this one included, treat it as an ordinary character: it becomes part of the first column's name, and a lookup for id fails against a key that is not quite id. Strip it, or import the file rather than double-clicking it.