Convert CSV to JSON

CSV is what every database, spreadsheet and analytics tool exports, and JSON is what every API, test fixture and configuration file expects. The gap between them is small and tedious, which is exactly the kind of gap worth having a tool for rather than writing a throwaway script each time.

The header row supplies the keys and every following row becomes one object — the shape almost everything downstream assumes. Quoted fields, escaped quotes and newlines inside a cell are parsed properly, so a CSV containing commas in an address field survives it, which a naive split on commas does not.

Types are inferred, and that is the part worth checking. Numeric-looking values become JSON numbers and `true`/`false` become booleans, which is nearly always what you want for quantities and flags.

It is the wrong answer for identifiers. `007` becomes `7`, and a postcode, a part number or a zero-padded account reference loses its leading zeros silently. If your data contains codes rather than quantities, look at the output before you rely on it — this is the single most common way a CSV to JSON conversion produces valid JSON and wrong data.

The whole thing runs in your browser, so a large export converts as fast as your machine allows and never leaves it. That matters more for this pair than for most: a CSV is very often a customer list, an order history or an export from a system somebody would rather not describe to a third party.

Since numeric-looking values become numbers, the defence for a column of codes is to make it unambiguous before converting: a leading apostrophe in the spreadsheet, a prefix, or exporting the column already quoted all mark it as text.

The general rule is worth internalising. If you would never add two values in a column together, it is an identifier and it wants to stay a string. Postcodes, part numbers, phone numbers and account references all fail the addition test.

An empty cell becomes null, not an empty string. A row reading 1,,3 under headers a,b,c arrives as {"a":1,"b":null,"c":3}, and that is a deliberate consequence of the same type detection that turns 1 into a number rather than "1".

It matters if the consumer distinguishes the two. A JSON Schema demanding a string will reject null; a database column declared NOT NULL will refuse the row. A CSV cannot express the difference between a field that was empty and one that was absent, so if that distinction carries meaning it has to be encoded explicitly in the source or restored afterwards. No converter can recover information the source format cannot carry.

Two columns sharing a header do not collide, which is the better outcome and still worth knowing about: the parser renames the second, so headers a, b, a produce the keys a, b and a_1. Nothing in the download says it happened, and a_1 appearing in your objects is the sign that the header row needed a glance.

A header row shorter than the data rows does not leave those values unnamed either. The surplus from each row is collected into one `__parsed_extra` array on that object, in the order the fields appeared. Fix the header in the CSV — it is a one-line change, and it is the only place that information exists.

The parse is fast and the limit is memory, because the whole array is built before it is written. Tens of megabytes is routine; hundreds is where a browser tab begins to strain.

For an export in that range the right tool is a streaming parser in a script rather than any browser-based converter. Saying so is better than failing halfway through a 900 MB file.

The output is an array of objects, which is what APIs, test fixtures and most libraries expect. It is not newline-delimited JSON, and it is not an object keyed by an ID column.

Both of those are a few lines of transformation away once you have the array, and neither can be chosen for you without knowing which column is the key. An array is the shape that assumes least.