CSV to JSON Converter

CSV, defined by RFC 4180 in 2005, is a flat grid: one header row names the columns, and every line below is a record whose fields line up by position. JSON, defined by RFC 8259 in 2017, is a tree — an array of objects where each value is reached by name rather than by column index. Moving data between them is the everyday work of exporting a Google Sheets or Microsoft Excel table into an API payload, or flattening an API response into something a spreadsheet can open. This converter runs both directions in your browser, and the interesting part is not the happy path but the four edge cases that a naive split-on-comma parser gets wrong.

The first trap is the comma inside a value. RFC 4180 says any field containing a comma, a double quote, or a line break must be wrapped in double quotes. So "New York, USA" is one field, not two, and a parser that splits the line on every comma shifts every column after it by one.

The second trap is the double quote inside a quoted field. RFC 4180 escapes it by doubling, so the six characters say ""hi"" become the five characters say "hi" after parsing. A parser that merely toggles a quote flag on each " silently deletes both quote marks and produces say hi, corrupting the value with no error at all.

The third trap is the newline inside a quoted field. Because a quoted value may legally contain a line break, you cannot split the file into rows before parsing — the moment you call split on the newline character you have already cut a two-line address field into two broken records. A correct reader walks the raw text one character at a time, tracking whether it is currently inside quotes, and treats a comma or newline as a delimiter only when it is outside them.

Nesting is the honest limit of any CSV export. CSV is two-dimensional: rows and columns, nothing deeper. JSON is a tree with no fixed depth. When a value in your JSON is itself an object or an array, there is no single column that can hold it faithfully. This converter does not silently render such a value as the useless string [object Object]; instead it serializes the nested structure back to compact JSON and places that text in the cell, so the information survives and you decide how to flatten it. If you need true flattening — turning user.address.zip into its own column — that is a schema decision only you can make, because the right shape depends on your downstream table.

Two boundaries are worth stating plainly. This is a line-and-field converter, not a type inference engine: everything coming out of CSV is a string, because CSV has no way to distinguish the number 30 from the text "30", and guessing wrong is worse than staying consistent. And the array passed to JSON→CSV must be a flat list of objects; a bare value, a lone number, or a deeply nested document raises a clear error rather than producing a misleading half-table. Within those limits the conversion is exact and reversible, and because every byte is parsed on your own machine, nothing you paste is uploaded anywhere.