How to Convert CSV to JSON (Headers, Delimiters and Type Inference Explained)

CSV and JSON are the two formats structured data spends most of its life in. CSV - comma-separated values - is what spreadsheets, exports and legacy systems produce: a plain grid of rows and columns. JSON - JavaScript Object Notation - is what APIs, config files and modern web apps expect: named fields, real numbers and booleans, and nesting to any depth. Converting CSV to JSON means turning that flat grid into a list of records a program can consume directly. This guide explains how the CSV to JSON converter reads your data, how it decides what is a number and what is text, which delimiter to choose, and walks through a worked example you can reproduce.

From a flat grid to a list of records

A CSV file is rectangular: one header line names the columns, and every line below is a row of values in the same order. JSON is happier as a list of self-describing objects, where each record carries its own field names. The converter bridges the two by reading the first row as a set of keys, then pairing those keys with the values on every following row. The result is a JSON array - one object per data row - that you can paste straight into code, hand to an API, or load into a document database.

What the converter gives you

You get an array, and its shape depends on a single toggle: whether the first row is treated as a header.

• With "first row is a header" on (the default), each following row becomes an object. The header cells are the keys, so a first line of name,age turns every later row into { "name": ..., "age": ... }. This is what you want almost every time.
• With it off, there are no key names to assign, so each row becomes an array of values instead - an array of arrays. Use this when your data is positional rather than labelled, or when the file genuinely has no header and its first line is real data you must not lose.

Numbers, booleans and the leading-zero trap

CSV has no types - every cell is just text. JSON does have types, so the converter can optionally read a bare number as a real number and the words true and false as booleans. That is the "convert numbers and true/false to typed values" option. It is deliberately strict: only text that is unambiguously a number is converted, which is what keeps your data honest.

The consequence worth knowing is leading zeros. A value like 0074 - a SKU, a ZIP code, part of a phone number - is left as the string "0074", because turning it into the number 74 would silently corrupt it. A plain 1200, though, becomes the number 1200. That means an identifier column can come out mixed: some values numbers, some strings. When a column holds labels rather than quantities, turn typing off so every value stays text and the column stays consistent. Thousands separators are left alone too - "1,000" stays a string, never the number 1000.

A worked example

Take this three-line CSV - a header plus two products, one with a quoted name containing a comma and one missing its price:

• sku,name,price,in_stock
• 0074,"Widget, deluxe",19.99,true
• 1200,Gadget,,false

With a comma delimiter, the header option on and typing on, the converter returns a two-object array:

• { "sku": "0074", "name": "Widget, deluxe", "price": 19.99, "in_stock": true }
• { "sku": 1200, "name": "Gadget", "price": "", "in_stock": false }

Four things are worth noticing. The quoted name "Widget, deluxe" stays a single value - its internal comma is not read as a column break. price 19.99 comes through as a real number and in_stock as real booleans. The missing price becomes an empty string rather than shifting the other columns out of line. And look at the sku column: 0074 kept its leading zero and stayed text, while 1200 became a number - exactly the mixed-type outcome that argues for turning typing off on ID columns. Paste those three lines into the CSV to JSON converter and you get this array back.

Choosing the right delimiter

"Comma-separated" is a loose description - plenty of CSV files separate fields with something else, and picking the wrong delimiter is the most common reason a conversion looks scrambled. The converter offers four:

• Comma - the default and the most common.
• Semicolon - standard across much of Europe, where the comma is the decimal separator, so 3,14 is a number and files use ; to divide fields instead.
• Tab - tab-separated values (TSV), common in database and spreadsheet exports where individual fields may themselves contain commas.
• Pipe - the vertical bar, used in data feeds and log-style records because it rarely appears inside real values.

If your output crams everything into one field, or splits in the wrong places, the delimiter is almost certainly the culprit - switch it to match the file and the columns fall into place.

Commas, quotes and line breaks inside fields

The parser follows the RFC 4180 conventions that spreadsheets use, so awkward values survive intact. A field wrapped in double quotes can contain the delimiter itself, so "New York, NY" is one value rather than two. It can also contain line breaks, so a multi-line address inside quotes stays a single cell. A literal double quote inside a quoted field is written as two quotes, which the parser collapses back to one. Blank lines are skipped rather than turned into empty records. If a conversion fails outright, the usual cause is an unbalanced quote - an opening quote with no closing partner - which leaves the parser reading the rest of the file as one long value.

It all runs in your browser

CSV exports are often the sensitive ones - customer lists, transactions, payroll. The CSV to JSON converter parses the text entirely inside your browser tab, so nothing is uploaded to a server and you can convert a spreadsheet of personal data without it leaving your machine. When you need the round trip the other way, the JSON to CSV converter reverses the process, and the JSON Formatter will pretty-print or validate the result before you use it.