CSV to JSON Without the Gotchas: Quotes, Delimiters, and Data Types
By the Super Simple Digital Tools Team · Updated June 2026
On paper, converting CSV to JSON sounds trivial: split each line on commas, pair the pieces with the header names, wrap it in brackets. In practice the messy reality of CSV files is where conversions go wrong. Real exports from spreadsheets and databases contain quoted fields, mixed delimiters, blank cells, and values that only look like numbers. A converter that ignores those details produces JSON that is valid but subtly wrong, and the bug usually surfaces later, deep inside whatever app consumed it.
The single most important rule comes from RFC 4180, the closest thing CSV has to a standard. Any field containing a comma, a line break, or a double quote must be enclosed in double quotes, and a quote that appears inside such a field is escaped by doubling it. That means the text she said ""hello"" inside quotes is one field holding she said "hello". A naive split on commas would shred a quoted address like "123 Main St, Apt 4" into two fields and throw off every column after it, so always confirm your parser respects quoting before trusting the output.
Delimiters are the next trap. The comma is the default, but plenty of files in the wild use semicolons or tabs. This is not random: Excel running in a European locale uses the comma as a decimal separator, so it switches the field delimiter to a semicolon to avoid collisions. Tab-separated values sidestep the whole issue because tabs carry no regional meaning. If your converted JSON comes out with one giant key per row, the delimiter setting is almost always the culprit, so peek at the raw file in a plain text editor and match the separator you see.
Then there is typing. CSV is pure text, so the cell 42 and the cell hello are stored identically as characters. JSON, by contrast, has real numbers, booleans, and null. Type inference bridges the gap by promoting 42 to a number and true to a boolean, which is exactly what you want for API payloads and schema-validated database imports. The danger is over-eager conversion: a ZIP code like 01234 becomes 1234, and long phone or account numbers can lose precision. The safe default for identifier-like columns is to keep them as strings.
Put it together and a reliable workflow emerges. Inspect the raw file to learn its delimiter and whether it has a header, choose array-of-objects output for the common case, decide consciously whether to infer types, then validate the JSON against whatever will consume it. Because everything runs in your browser, you can iterate on a sensitive export without it ever leaving your machine. Spending thirty seconds on these checks is far cheaper than chasing a malformed record through a production pipeline.
- Open the raw CSV in a plain text editor first to confirm the real delimiter (comma, semicolon, or tab) before converting.
- Keep type inference off for ZIP codes, phone numbers, and IDs so leading zeros and precision survive the conversion.
- If a quoted field contains a quote, make sure it is escaped by doubling it ("") rather than with a backslash, which CSV ignores.
- Use array-of-objects output for APIs and databases; switch to indexed or array output only when your file has no header row.