CSV to JSON Converter

CSV looks like the simplest format in existence right up to the moment you have to parse it. It has no types, no schema, no declared encoding, no agreed delimiter, and no way to express nesting — and yet it is still how most systems hand data to each other, because every spreadsheet in the world can produce it. Converting it to JSON means supplying all the structure that CSV never had, and being clear about which parts are inference rather than fact.

This converter detects the delimiter automatically, handles quoted fields containing commas and embedded newlines, uses your header row for the object keys, and converts values that look numeric or boolean into real JSON types. Everything runs in your browser in a Web Worker, which matters because the CSV you are pasting is very often a customer or payroll export.

What is inferred, and where inference goes wrong

CSV stores text. Everything in it is a string on disk, so any JSON number or boolean in the output is the result of a guess. That guess is right most of the time and disastrous a small percentage of the time:

• Numbers. 129.00 becomes the number 129, losing the trailing zero that indicated currency precision. 1e5 becomes 100000.
• Leading zeros are destroyed. A Singapore postcode 049483, a German account number, a UK sort code, a zero-padded SKU — all become integers with the leading zero gone. This is the single most damaging inference and it is silent.
• Long identifiers lose precision. A 19-digit Snowflake ID exceeds the range JavaScript numbers can represent exactly, so the last digits change. The value looks plausible and is wrong.
• Booleans. true and false become JSON booleans. Values such as yes, Y and 1 stay as they were written.
• Empty cells become empty values. There is no way to know whether an empty cell meant null, an empty string, or "not applicable", so the distinction is simply not available.

If any of those columns matter to you, the pragmatic fix is to post-process the JSON — cast the fields you know are identifiers back to strings — or to pre-process the CSV so identifier columns are unambiguous. No parser setting can distinguish a postcode from a number, because at the CSV level there is genuinely no difference.

Delimiters, quoting and encoding

The parser detects the delimiter by scanning the first rows and choosing the candidate that produces a consistent field count. Comma is the default assumption, but semicolon-delimited files are extremely common in European locales, where the comma is the decimal separator and Excel switches delimiter accordingly. Tab and pipe are also detected. The delimiter it settled on is reported with the output; if it looks wrong, the file is probably inconsistent.

Quoting follows RFC 4180. A field wrapped in double quotes may contain the delimiter, line breaks, and doubled double quotes as literal quote characters. That is why the example on this page parses into four records even though it spans more lines than that — one note field contains a real newline inside a quoted field. Naive splitting on commas and newlines, which is what most hand-rolled parsers do, mangles exactly this case.

Header names are trimmed of surrounding whitespace, since exports frequently pad them. Blank lines are skipped rather than producing empty objects. A UTF-8 byte order mark at the start of the file, which Excel adds on Windows, is handled so your first key is not named with an invisible character prefix.

Duplicate header names are the remaining hazard: two columns both called name cannot both become the key name in one object, so one wins. Rename the columns before converting if your export has duplicates.

Ragged rows and what CSV cannot express

A row with more or fewer fields than the header row is reported as a note rather than treated as fatal, and the conversion continues. This is deliberate: a single malformed row in a 20,000-line export should not cost you the other 19,999. Read the notes, find the row, and decide whether it is a data problem or a quoting problem — an unescaped quote character in one field is the usual cause, and it typically corrupts the row after it too.

The deeper limitation is that CSV is flat, so the JSON you get is flat. A column named plan.code becomes a key literally called "plan.code", not a nested plan object with a code property. If the CSV came from the JSON to CSV tool, the dotted names are still there and you can rebuild the nesting with a few lines of code on your side, but this converter does not attempt it — inferring structure from key names would be guesswork, and a column genuinely named version.1 would be silently restructured.

Turning the header switch off gives you an array of arrays instead of an array of objects, which is the right shape for a headerless data file or when you want positional access.