When is CSV to JSON useful?
CSV to JSON is the reverse trip: a spreadsheet export becomes an array of records that a script can read. The first row supplies the keys and every later row becomes one object. That single convention is why the format is everywhere, and it is also where most of the surprises live. If the header row has a typo, the typo becomes a key. If a header is blank, the page gives it a positional name such as column_3 so no data is dropped. If the same header appears twice, the second column would overwrite the first, so the page reports the duplicate instead of quietly losing a field.
Types are guessed from the text, because CSV carries no type information of its own. A value that looks like a whole number or a decimal becomes a number, true and false become booleans, and null becomes a JSON null. Anything else stays a string, which is the safe default: an order code of 007 keeps its leading zeros because it does not match the numeric pattern. An empty cell becomes an empty string rather than null, so you can tell a missing value from a value that was never typed. Quoted fields containing commas, line breaks, or doubled quotes are parsed first and then written into JSON as ordinary strings.
The output is a pretty-printed array with two-space indentation, ready to paste into a config file, a test fixture, or a request body. Because the conversion happens in the page, the file never leaves the machine, which matters for exports that contain personal data. A CSV with a single row has no records, only keys, so the page returns an empty array in that case. If a row has the wrong number of fields, the parser reports the row number and the expected count instead of pushing values into the wrong keys. Rows are not merged, sorted, or deduplicated; the order in the file is the order in the output.