JSONBench

CSV and JSON, both directions

A proper parser — quoted fields, commas inside quotes and newlines inside cells all survive.

Network measuring… Your data never leaves this tab

Why splitting on commas fails

The intuitive way to parse CSV is to split each line on commas. It works on the example file and fails on real data, because CSV allows a field to contain a comma as long as the field is quoted — and real data is full of them. "Reid, Ana" is one field, not two. So is an address, a job title with a comma, or any free-text note.

It gets worse: a quoted field may contain a newline, so a single record can span several lines, and any parser working line by line has already lost. And a literal double quote inside a quoted field is written as two double quotes, which a naive parser reads as the end of the field followed by the start of another.

This converter walks the file character by character and tracks whether it is inside a quoted field, which is the only approach that handles all three. The example button loads a file containing all of them, so you can see it survive.

The leading-zero problem

Automatic type conversion is convenient and occasionally destructive. The dangerous case is a value like 007 or 0212345678 — a product code, a postcode, a phone number. Converted to a number it becomes 7 or 212345678, and the leading zeros are gone for good.

So anything with a leading zero stays a string here, as does any integer too large for JavaScript to represent exactly. You lose a little tidiness and you keep your identifiers.

Questions

Does it handle commas inside quoted fields?
Yes, and this is the thing most converters get wrong. Splitting each line on commas is the obvious implementation and it breaks on the first address, full name or free-text note in the file. This uses a real character-by-character parser: quoted fields, commas inside quotes, doubled quotes as an escaped quote, and newlines inside a quoted field all survive intact.
Are numbers converted automatically?
Carefully. A plain integer or decimal becomes a number, and true/false become booleans. But anything with a leading zero stays a string, because 007 and 0123 are almost always identifiers — postcodes, product codes, phone numbers — and turning them into 7 and 123 silently destroys them. Values beyond JavaScript's safe integer range also stay strings rather than losing digits.
What if my rows have different columns?
Going from JSON to CSV, the header is the union of every key across every object, so nothing is dropped and missing values become empty cells. Going the other way, every row gets every header key. That is the lossless choice; some converters use only the first object's keys and quietly discard the rest.
Can it handle semicolon or tab separated files?
Yes, pick the delimiter. Semicolons are the norm in much of Europe, where the comma is the decimal separator — opening such a file with a comma delimiter is the classic cause of a spreadsheet that looks shredded.