CSV to JSON Converter

CSV is not a format you can split on commas

It looks like the simplest format there is, which is exactly why so much code gets it wrong. RFC 4180 lets any field be wrapped in double quotes, and a quoted field may contain commas, line breaks, and quotes — the last written as two quotes in a row. Splitting on commas handles none of that.

Wrong on 3 of 6 entirely ordinary rows — a customer name, a price with a thousands separator, a street address. And always wrong in the same direction, producing too many fields, which is why it usually surfaces as a column-count mismatch far away from the actual cause.

The greyed rows are the ones it gets right. Notice that a plain row with no quoting is among them: naive splitting works perfectly on the test data most people write, and fails on the real data that arrives later. That is the shape of a bug that ships.

And a row is not a line

One case does not just break the splitting — it breaks the shape of the program. A quoted field is allowed to contain a newline. So this:

id,note
1,"line one
line two"
2,ok

is 4 lines of text and 3 rows of CSV. The middle row's second field contains a line break, and it is supposed to. No amount of care about the splitting fixes this, because the row boundary and the line boundary are different things. Any program built around "read a line, then parse it" cannot represent the data at all.

The correct approach is to walk the text character by character, tracking whether you are currently inside a quoted field. That is about thirty lines of code and it is what this converter does. Feeding it the same awkward data — names with commas, embedded quotes, a multi-line cell, empty and space-padded fields — and writing it back out gives:

name,note,qty
"Smith, John","said ""hi""",3
"multi
line",plain,0
,empty name,1
trailing space , leading,2

That round-trips back to the original 5 rows exactly — checked on every build, along with 3,000 generated rows built from commas, quotes and newlines. A line-splitting reader given the same text finds 6 rows instead of 5, and reports no error while doing it.

Writing CSV has the same rules in reverse

Going the other way, a field needs quoting if — and only if — it contains a comma, a double quote, or a line break. Quotes inside get doubled. Everything else is written bare, which keeps the file readable:

One thing worth flagging because no rule can fix it: a trailing empty field is genuinely ambiguous in CSV. The line a,b, could be three fields with the last one empty, or two fields with a stray comma, and the format does not say which. Most parsers choose three. If your data can end in an empty value, that is a place to check what the other end assumes rather than trust it.