CSV to JSON Converter — turn spreadsheet exports into clean JSON

The CSV to JSON converter above reads a comma (or semicolon, tab, or pipe) separated file and turns each row into a JSON object, using the first row as field names. Unlike a quick .split(',') script, it correctly handles quoted fields that contain the delimiter itself, escaped quotes, and blank cells — all entirely client-side, in your browser.

Arb Digital builds data pipelines like this for clients migrating spreadsheet workflows into real applications, and this tool is the free, public version of the parsing logic we rely on internally.

What This CSV to JSON Converter Does

You paste CSV text, choose the delimiter your file actually uses, and tell the tool whether the first row is a header. It then parses the file row by row, respecting quoted fields, and produces a JSON array — either an array of objects (keyed by the header) or an array of arrays (if there's no header row). The result panel reports how many records were parsed and how many fields each one has, so you can immediately spot a malformed row.

How to Use It

1. Paste your CSV. Copy it straight from a spreadsheet export, a database dump, or a log file.
2. Pick the delimiter. Most US exports use a comma; many European ones use a semicolon; tab-separated files (TSV) and pipe-delimited exports are common in data warehousing.
3. Set the header toggle. If row one contains column names, leave "Yes" selected so they become the JSON object keys. If the file is pure data with no header, switch to "No" to get an array of arrays instead.
4. Click Convert to JSON and copy the result from the output box.

Why Naive Comma-Splitting Breaks

The obvious way to "parse CSV" is to split each line on commas. It works for the simplest files and fails the moment a real one shows up — because CSV allows a field's value to contain the delimiter, as long as the whole field is wrapped in double quotes. A note field like "Prefers email, not calls" has a comma inside it that is part of the data, not a column separator. A naive splitter turns that one field into two columns and shifts every subsequent column in the row out of alignment, corrupting the rest of that record silently — no error, just wrong data.

Handling this correctly requires a real state-machine parser, not a one-line split: the parser has to track whether it's currently "inside" a quoted field, and while it is, it treats commas, newlines, and everything else as literal characters rather than structure. It also has to handle the CSV escaping convention for a literal double quote inside a quoted field — two double quotes in a row ("") represent one literal " character, as defined in RFC 4180. This tool's parser reads the CSV character by character, tracking quote state, so a field like "Says ""call after 5pm""" is correctly parsed as the single value Says "call after 5pm".

Choosing the Right Delimiter

"CSV" is often used loosely to mean "delimited text," even when the actual delimiter isn't a comma. This matters more than it might seem: in many European locales, the comma is already the decimal separator for numbers (as in 1.234,56), so spreadsheet software in those regions defaults to exporting fields separated by semicolons instead, to avoid ambiguity. Tab-separated values (TSV) are common where fields might contain commas AND you want to avoid quoting altogether, since tabs rarely appear in the data itself. Pipe-delimited files show up frequently in legacy data warehouse exports.

Getting the delimiter wrong produces a very specific, recognizable failure: either every row parses as a single giant field (delimiter set too narrow) or fields split in the wrong places (delimiter set too permissive, matching characters that appear inside quoted values). If your "Fields per record" count in the result panel looks obviously wrong — 1 field, or way more than the columns you expect — the delimiter selection is the first thing to check.

Why Type Inference Is a Trap

It's tempting to have a CSV-to-JSON converter get "smart" and convert numeric-looking strings to actual numbers, or "true"/"false" strings to booleans. This tool deliberately does not do that, and for good reason: CSV has no type system at all, so any inference is a guess, and guesses are wrong often enough to cause real damage. A ZIP code like "02134" becomes the number 2134 if you auto-convert it, silently dropping the meaningful leading zero. A product SKU like "1E5" can be misread as scientific notation. An ID column that happens to contain only digits for the first thousand rows can suddenly include a value like "00A123" further down, and a type-inferring parser would treat that row inconsistently from the rest.

Keeping every value as a string by default means the output is predictable and lossless — what you see in the CSV is exactly what you get in the JSON, character for character, and any type conversion you actually want happens deliberately, downstream, where you can control it.

Handling Missing and Extra Fields

• A row with fewer fields than the header still produces an object with all header keys; missing trailing fields become empty strings.
• A row with more fields than the header (a common sign of a data entry mistake, or an unescaped delimiter somewhere earlier in the row) still parses — the extra values are kept using numeric fallback keys so no data is silently dropped.
• Blank lines in the pasted CSV are skipped rather than turned into empty objects.
• A trailing newline at the end of the file doesn't create a phantom extra record.

A Worked Example: Support Notes With Embedded Commas

Look at the sample data pre-loaded in the tool above: a notes column with values like "Prefers email, not calls" and "Says ""call after 5pm""". Both of those are single, valid CSV fields, but both would confuse a naive parser in different ways. The first contains a comma that isn't a column separator; strip the quotes incorrectly and you'd get a phantom extra column starting with not calls. The second contains an escaped double quote in the middle of the text; miss the doubled-quote rule and the parser would think the quoted field ends right after Says, then get confused by the stray characters that follow.

Run that sample through the converter and you'll see three clean JSON objects, each with a notes field holding the full, correctly-unescaped sentence — including the literal double quote around "call after 5pm" in the second record. That's the entire value proposition of a real parser over a quick script: the edge cases that show up constantly in real support tickets, product reviews, and free-text fields are handled correctly by default, not as an afterthought.

JSON Output Shape: Objects vs. Arrays

The header toggle changes more than just whether keys have names — it changes the entire shape of the output, which matters for how downstream code consumes it. With "First row is header" set to Yes, each record becomes a JSON object like {"id": "1", "name": "Ava Chen"}, which is usually what you want when feeding the data into code that accesses fields by name, or into another tool (like a database importer) that expects named columns. With it set to No, each record becomes a plain array like ["1", "Ava Chen"], which is more compact and appropriate when you're treating the CSV as a raw matrix of values — for example, loading it straight into a spreadsheet-like grid component where columns are addressed by position, not name.

If you're not sure which your downstream code expects, objects (header mode) are the safer default: they're self-documenting, and reordering columns in the source CSV won't silently reorder the meaning of your data the way a positional array would.

Common Mistakes to Avoid

• Picking the wrong delimiter. If your columns look wrong after converting, check whether the source file actually uses semicolons or tabs instead of commas.
• Forgetting the header toggle. If your first row is data, not column names, and you leave "Yes" selected, you'll lose that row as data and get oddly-named keys.
• Assuming numbers stay numbers. Every value comes out as a JSON string by design; convert types explicitly in your own code if you need numbers or booleans.
• Copy-pasting from a rendered spreadsheet view instead of exporting an actual CSV file, which can silently reformat dates or drop leading zeros before the text even reaches this tool.
• Not checking the "Fields per record" count after conversion — it's the fastest way to catch a delimiter or quoting problem before you rely on the output.

Related Free Tools From Arb Digital

Need to go the other direction? Use our JSON to CSV Converter. Want to confirm the resulting JSON is well-formed? Try the JSON Validator or beautify it with the live JSON Formatter. Working with other data formats? See the YAML to JSON Converter and the SQL Formatter. Browse everything in our free online tools hub.

Frequently Asked Questions