CSV and JSON describe data differently enough that converting between them requires choices. Making those choices up front avoids a set of failures that are easy to miss until much later.
The shape mismatch
A CSV is a rectangle: rows and columns, all values flat strings.
JSON is a tree: nested objects, arrays, and four scalar types (string, number, boolean, null).
The natural mapping is one CSV row to one JSON object, with column headers as keys:
id,name,active
1,Asha,true
2,Ben,false
[
{ "id": 1, "name": "Asha", "active": true },
{ "id": 2, "name": "Ben", "active": false }
]
Straightforward, but notice that 1 became a number and true became a boolean. Those were decisions, and they are where things go wrong.
Type inference is the main hazard
Every value in a CSV is a string. A converter that infers types is guessing, and the guesses are frequently wrong in ways that destroy data:
00745→ the number745. Leading zeros gone. Postcodes, SKUs and account numbers ruined.+91 98765 43210→ possibly a number, possibly mangled.4532015112830366→ exceeds JavaScript's safe integer range (2⁵³−1) and is silently rounded.0123→123, breaking any identifier that depends on its exact form.TRUE,yes,Y,1→ treated as booleans by some converters and not others.2026-07-08→ a string in JSON (there is no date type), but some converters reformat it anyway.
The safe default is keep everything as a string, then explicitly cast the specific fields you know should be numeric. Losing the number type is recoverable; losing the leading zeros is not.
Empty values are ambiguous
An empty CSV field could mean an empty string, a missing value, or a genuine null. CSV cannot distinguish them.
Pick a convention and apply it consistently, usually empty string becomes null for numeric columns and "" for text columns. What matters is that consumers know which rule you used.
Watch for literal NULL, N/A, - and #N/A strings, which are common in exported data and mean "missing" to a human but are ordinary text to a parser.
Nesting
CSV is flat, so representing structure requires a convention. The common one is dotted headers:
id,address.city,address.pin
1,Ahmedabad,380001
[{ "id": "1", "address": { "city": "Ahmedabad", "pin": "380001" } }]
Arrays are harder: either repeat a column with an index (tags.0, tags.1) or put a delimited list inside one field ("red;green;blue"), which requires a second delimiter that does not appear in the data.
Going the other way, JSON to CSV, you must flatten, and any array of variable length forces either a column per possible position or a joined string. There is no clean answer; decide based on what the consumer needs.
Headers need cleaning
CSV headers from real exports contain spaces, punctuation, currency symbols and trailing whitespace. Total (₹) is a valid JSON key but awkward to use in most languages.
Normalise to something predictable, total_inr, and keep a mapping if the original labels matter for display.
Also check for duplicate headers. Two columns named name produce a JSON object where one silently overwrites the other.
When output size matters
JSON repeats every key in every record. For a 100,000-row file, that is the column names written 100,000 times. JSON is typically two to three times larger than the equivalent CSV.
For large exports, consider NDJSON, one JSON object per line. It streams, it can be processed line by line without loading everything into memory, and a single malformed line does not invalidate the file.
A conversion checklist
- Confirm the delimiter and encoding before parsing anything.
- Decide the type policy, strings by default, cast explicitly.
- Normalise headers; check for duplicates.
- Decide how empty values are represented.
- Validate the output parses as JSON.
- Spot-check the first, last and a middle record against the source, paying attention to any identifier column.
Steps 1 and 6 catch most problems. A CSV to JSON converter that lets you preview the parsed result before committing makes both quick, and running it in the browser means a customer export never leaves your machine on the way.