CSV to JSON Converter
Convert between CSV and JSON in either direction, handles quoted fields, embedded commas, and escaped quotes correctly.
About the CSV to JSON Converter
Converting CSV to JSON relies on a character-by-character parser rather than a simple split on commas, so quoted fields with embedded commas, line breaks, or escaped double quotes ("") come through correctly in both directions. Going the other way, JSON to CSV expects an array of flat objects and assembles the header row from the union of every key it finds.
Why a naive comma-split would corrupt real-world CSV files
Splitting a CSV line on every comma seems obvious until a field itself legitimately contains a comma, like a name written "Smith, John" that needs to stay in one field, not become two. The standard CSV convention (formalized in RFC 4180) wraps such fields in double quotes, and a literal double quote inside a quoted field is escaped by doubling it, "". This parser tracks an inQuotes state as it reads character by character: while inside quotes, commas and line breaks are treated as plain text rather than delimiters, and encountering "" specifically inserts a single literal quote character rather than ending the quoted section. That state tracking is exactly what a simple .split(",") can't do, and it's why hand-rolled, char-by-char CSV parsers are the reliable way to handle real-world exported spreadsheets rather than a one-line string split.
Why nested JSON objects and arrays get explicitly rejected
CSV is inherently a flat, two-dimensional grid, rows and columns, with no native way to represent a value that's itself an object or array. If your JSON input contains a nested object or array as one of its field values, this tool doesn't try to force it into a cell anyway (which would typically produce a useless [object Object] string or silently drop the nested data), it throws a clear error explaining that every item must be a flat object. That's a deliberate choice to fail loudly and explain the structural mismatch, rather than quietly producing a CSV file that looks fine but has actually lost information.
Why the header row comes from every object's keys, not just the first one
Real-world JSON arrays don't always have perfectly consistent keys across every object, some records might be missing an optional field, or have an extra one nobody else has. If this tool only looked at the first object to build the CSV header, any keys that first object happened to lack would silently vanish from the output entirely, even if later objects had them. Instead, it walks every object in the array and builds a header row from the union of every key seen anywhere, so no column gets dropped just because of which object happened to come first, any object missing a particular key simply gets an empty cell in that column.
Only quoting fields that actually need it
When converting JSON back to CSV, a field only gets wrapped in quotes if it actually contains a comma, a quote, or a line break, plain values pass through unquoted. This "minimal quoting" approach matches how well-formed CSV is conventionally written and keeps the output more compact and readable than a maximal-quoting approach that wraps every single field regardless of content, while still being fully valid, unambiguous CSV either way.
Why the JSON-to-CSV output uses CRLF line breaks specifically
The generated CSV joins its rows with \r\n (carriage return plus line feed) rather than a plain \n. This isn't an accident, RFC 4180, the closest thing CSV has to an official specification, recommends CRLF line endings for maximum compatibility, since some older spreadsheet software and Windows-oriented tools specifically expect that line-ending convention. The CSV parser going the other direction is more permissive, it strips \r characters outright, so it transparently accepts CSV files using either Windows-style CRLF or Unix-style LF line endings without you needing to know or care which one a given file uses.
Frequently Asked Questions
Why can't a simple comma-split handle real CSV files correctly?
Fields can legitimately contain commas when wrapped in quotes, like "Smith, John". A naive split on every comma would incorrectly break that single field into two. This tool tracks whether it's currently inside a quoted field character by character, so commas within quotes are treated as text, not delimiters.
What happens if my JSON has nested objects or arrays as field values?
The converter throws a clear error rather than attempting the conversion, since CSV is a flat, two-dimensional format with no way to represent nested structures. This avoids silently producing a CSV with useless [object Object] text or quietly dropping the nested data.
What happens if some objects in my JSON array have different keys than others?
The header row is built from the union of every key found across all objects in the array, not just the first one. Objects missing a particular key simply get an empty cell in that column, so no column gets silently dropped due to key inconsistency.
Does every field in the output CSV get wrapped in quotes?
No, only fields that actually contain a comma, a quote character, or a line break get quoted. Plain values pass through unquoted, keeping the output more compact and closer to how well-formed CSV is typically written by hand.
Why does the generated CSV use \r\n instead of just \n for line breaks?
RFC 4180, the closest thing to an official CSV specification, recommends CRLF line endings for maximum compatibility with spreadsheet software and Windows-oriented tools. The parser accepts either line-ending style when reading CSV back in, regardless of which one a source file uses.
How are escaped quotes inside a CSV field handled?
A doubled double-quote ("") inside a quoted field represents one literal quote character, the standard CSV escaping convention. The parser specifically detects this pattern and inserts a single quote character into the field rather than treating it as the end of the quoted section.