Why JSON to CSV Breaks on Commas in Quotes

A single JSON value like "Berlin, Germany" or "Smith, John" can silently shift every column to its right once it lands in a CSV. CSV uses the comma as the column separator, so if that value is written into the file as plain, unquoted text, the comma inside it looks exactly like a new column boundary. A 5-column row turns into 6 fields, everything after the broken value slides one column over, and the corruption often isn't visible until someone opens the file in a spreadsheet and notices a phone number sitting in the "city" column three rows down. This is the exact symptom behind forum threads titled things like "CSV import is splitting JSON data into their own columns" — the data wasn't malformed, the CSV just wasn't quoted.

This breaks because the converter (often a hand-rolled script) builds each CSV row by joining values with `,` directly, or reads a row back by calling something like `line.split(",")` — treating every comma as a delimiter with no awareness that some commas belong *inside* a value. CSV's actual rule is that a comma only separates columns when it's outside double quotes; a naive implementation never checks for quotes at all, so it can't tell "a value with a comma" from "two values". The same failure mode shows up on the read side too: a hand-rolled parser that splits on every comma will happily cut a quoted "Smith, John" into two cells instead of treating the quotes as "one field, don't split here."

The fix is the standard CSV quoting rule (RFC 4180): any field containing a comma, a double quote, or a newline gets wrapped in double quotes, and any double quote that appears inside the value is escaped by doubling it (`"` becomes `""`). So `Berlin, Germany` is written as `"Berlin, Germany"`, and a value like `He said "hi"` is written as `"He said ""hi"""`. A correct CSV reader then knows that once it sees an opening quote, commas and newlines inside it are literal characters, not delimiters, until it hits the matching closing quote. This is a solved problem — it just requires the converter to actually implement quote-awareness on both the write and read side, instead of treating CSV as "just join/split on commas."

pixeltools' JSON/CSV/YAML converter doesn't hand-roll comma-joining at all — it hands the row data to `Papa.unparse()` from the papaparse library to generate the CSV output, and to `Papa.parse()` (with `header: true`) to read CSV back in. papaparse implements RFC 4180 quoting automatically: it wraps any field containing a comma, double quote, or newline in double quotes and doubles any internal double quotes, with no per-field logic the converter has to get right itself. That's the direct, code-level reason a value like `Berlin, Germany` or `Smith, John` survives a round trip through this converter as one column, not two — there's no `value.split(",")` anywhere in the path that could shift columns.

Open the raw CSV file in a plain text editor, not a spreadsheet — a spreadsheet app will happily *display* a broken file as if it were fine, because it's doing its own comma-guessing on import. Look for any field that contains a comma, a quote, or a line break: in a correctly quoted file, it will be wrapped in double quotes (`"Berlin, Germany"`), and any literal quote inside it will appear doubled (`""`). If you instead see the comma sitting unquoted in the middle of a row, or a field cut in half at the comma, the file was generated (or parsed) without proper CSV escaping, and every downstream column count is now unreliable for that row.

Removing commas from your JSON values isn't the fix — it's a workaround that loses information ("Berlin, Germany" becoming "Berlin Germany") to paper over a converter that never implemented quoting. The actual bug reports behind this exact search — GitHub issues against json-2-csv, csvtojson, and similar libraries — are converter-side quoting/escaping defects, not malformed source data. If a tool's output shifts columns whenever a value has a comma, or its "escaping" produces backslash-comma instead of a quoted field, that tool doesn't implement RFC 4180 quoting correctly, and swapping it for one that does (rather than editing your data) is the real fix.