This is the everyday conversion for developers pulling a spreadsheet export into a script, API payload, or config file. Each CSV row becomes one JSON object, keyed by the header row, with numbers and booleans inferred rather than left as strings. It handles quoted fields, embedded commas, and multi-line cells correctly, which is where naive hand-rolled parsers usually break.
CSV has no types, JSON does
Every value in a CSV file is text. The number 42, the word forty-two and the date 2026-01-31 are stored identically, as characters between delimiters. JSON distinguishes numbers, strings, booleans and null, so converting between them means deciding, for every single cell, what type it was meant to be.
That inference is where conversions go wrong in ways that are easy to miss. A product code like 007 becomes the number 7 and loses its leading zeros. A long identifier can exceed what a double-precision number holds and quietly lose its last digits. A column of postcodes with entries like 1E5 is read as scientific notation. If a field is an identifier rather than a quantity, check it survived.
Quoting is where malformed files break
The header row becomes the keys of each object and every subsequent row becomes one object, which is the straightforward part. The parsing underneath is less so, because CSV is a convention rather than a strict standard. Fields containing a comma have to be quoted; fields containing a quote have to escape it by doubling it; a field can legitimately contain a line break inside its quotes, so a row is not the same thing as a line.
Files exported by real systems break these rules regularly, and the usual symptom is one row that has more columns than the header, or a run of rows collapsing into one. If the output looks shifted partway through, the source is usually a stray unescaped quote rather than anything the conversion did.