CSV looks like the simplest format in the world: rows of values separated by commas. Converting it to JSON should be trivial, and for clean data it is. The trouble starts the moment your CSV contains a comma inside a value, a quote inside a quote, or a header row you did not expect. This guide walks through the format, the two shapes JSON can take, and the type traps that catch almost everyone.
You can do the whole thing without leaving your browser using the CSV to JSON converter. This post explains what the tool is doing so you can trust the output and debug messy input.
What CSV actually specifies
CSV is not one format; it is a loose family of conventions with a rough standard (RFC 4180) that many producers ignore. A row is a line and fields are separated by a delimiter, and that is where the easy part ends.
The delimiter is usually a comma, but plenty of European exports use a semicolon because the comma is a decimal separator there. Tab-separated values (TSV) are the same idea with a tab. Confirm which delimiter your file uses before parsing; guessing wrong turns one column into many or many into one.
The header row is optional. Most files put field names on the first line, but some ship raw data with no header. Your converter has to know which case it is looking at, because the header decides whether keys come from the file or have to be invented.
The quoting rules that break naive splitting
The single biggest mistake is splitting each line on the delimiter. It works until a value contains that delimiter. CSV solves this by wrapping such values in double quotes, and a correct parser has to honor three rules:
- A field wrapped in double quotes may contain the delimiter as literal text.
Smith, Johnbecomes"Smith, John"and stays one field. - A quoted field may contain newlines. A single record can span several physical lines.
- A literal double quote inside a quoted field is escaped by doubling it.
She said "hi"becomes"She said ""hi""".
Consider this input:
name,note
"Doe, Jane","Said ""yes"" today"
"Multi
line","ok"
A line.split(",") approach mangles all three rows. A real parser reads it as two records: one with the value Doe, Jane and the note Said "yes" today, and one whose name contains a newline between Multi and line. If your output has the wrong number of fields, unescaped quotes are almost always the cause.
The two shapes of JSON output
Once the CSV is parsed into rows, you have to decide what JSON to emit. There are two standard shapes.
The most common is an array of objects, which uses the header row as keys:
[
{ "name": "Doe, Jane", "note": "Said \"yes\" today" },
{ "name": "Multi\nline", "note": "ok" }
]
This is readable, works directly with most APIs and databases, and is the right default when your CSV has a header.
The second shape is an array of arrays, which keeps every row as a positional list:
[
["name", "note"],
["Doe, Jane", "Said \"yes\" today"],
["Multi\nline", "ok"]
]
This is compact, preserves column order, and is useful when there is no header or when duplicate column names would collide as object keys.
Everything is a string until you cast it
CSV has no types. The values 42, true, and 2026-07-04 are all just text between delimiters. JSON, by contrast, distinguishes numbers, booleans, null, and strings. Converting means deciding whether to cast.
The safe default is to keep every field as a string, so "age": "42" never surprises you. The convenient option casts values that look like numbers or booleans, giving "age": 42. Convenience has sharp edges:
- Leading zeros vanish. A zip code
01960becomes1960if cast to a number, which is wrong. - Long identifiers lose precision. A 20-digit order number exceeds what a JSON number can hold exactly.
TRUE,True, andyesmay or may not be treated as booleans depending on the parser.- An empty field could mean empty string,
null, or a missing key. Decide which.
If your downstream code expects strings, do not let the converter cast. If it expects typed values, cast deliberately and re-check the cases above. When in doubt, keep strings and cast later in code where you control the rules.
Common gotchas before you ship
A few last traps. A byte order mark (BOM) at the start of an Excel file can attach invisible characters to your first key, so name silently becomes name. Trailing empty lines produce an extra empty record. Windows line endings (\r\n) can leave a stray \r on the final field of each row if the parser only splits on \n. And ragged rows, where some lines have fewer fields than the header, force a choice between padding with null and rejecting the row.
Once you have valid JSON, run it through the JSON formatter to pretty-print and confirm it is well formed. If your real goal was a readable table, the CSV to markdown table tool skips JSON entirely.
The short version
Confirm the delimiter, respect quoted fields and doubled quotes, choose array of objects when you have a header and array of arrays when you do not, and keep values as strings unless you have a reason to cast. Do that and CSV to JSON stops being fiddly. The CSV to JSON converter applies all of these rules in your browser, with nothing sent to a server.