CSV to JSON Converter

This tool converts CSV (comma-separated values) to JSON in your browser. The CSV is parsed locally; nothing leaves your machine. For the inverse direction, see JSON to CSV.

The basic conversion

CSV:
name,age,city
Alice,30,New York
Bob,25,Boston

JSON:
[
  {"name": "Alice", "age": "30", "city": "New York"},
  {"name": "Bob",   "age": "25", "city": "Boston"}
]

The first row is the header — column names become object keys. Every subsequent row becomes an object whose values come from the corresponding columns.

The tool above defaults to this shape: an array of objects, with the first CSV row as keys.

CSV is harder than it looks

CSV has no formal universal specification. RFC 4180 is the closest thing to a standard, but real-world CSV varies on every field:

• Delimiter. Comma is the default; tab is common (TSV); semicolon is common in European locales (where comma is the decimal separator).
• Quote character. Double quote " is the RFC 4180 standard; some files use single quotes; some use no quoting at all.
• Escape inside quotes. Doubled quotes ("") is RFC 4180; backslash escape (\") is also seen.
• Line endings. \r\n per RFC, but \n is widespread on Unix-origin files.
• Whitespace. Some CSV has spaces around commas ("Alice", "30"); some has trailing whitespace; some has leading BOMs.
• Header. Sometimes present, sometimes not.

A CSV parser has to make decisions about all of these. The tool above follows RFC 4180: comma-delimited, double-quoted fields with "" for a literal quote, \r\n or \n line endings, first row as the header. For semicolon- or tab-delimited files, convert the delimiter first (see TSV to CSV).

Type handling

CSV values are all strings. JSON has strings, numbers, booleans, and null. A parser has to decide whether to coerce:

CSV:
id,active,price,note
1,true,9.99,
2,false,12.50,sale

Strict JSON (everything stays string):
[
  {"id": "1", "active": "true", "price": "9.99", "note": ""},
  {"id": "2", "active": "false", "price": "12.50", "note": "sale"}
]

Type-coerced JSON:
[
  {"id": 1, "active": true, "price": 9.99, "note": null},
  {"id": 2, "active": false, "price": 12.50, "note": "sale"}
]

Both are valid interpretations. Type coercion is convenient but risky:

• A column with leading-zero strings ("007") might coerce to the number 7, losing the format.
• "true" and "TRUE" and "True" all become true if booleans are coerced.
• An empty cell becomes null, but is the cell missing or empty? CSV doesn’t distinguish.
• Phone numbers, ZIP codes, credit card numbers — all “look numeric” but should remain strings.

The tool above keeps every value as a string (the strict form), so 007 stays "007". If your consumer wants numbers and booleans, convert those columns after parsing, where you know which ones they are.

Edge cases inside cells

CSV:
name,description
Alice,"30 years old, lives in NYC"
Bob,"says ""hello"""
Charlie,"line one
line two"

Three cases to handle:

• Comma in a value. Wrapped in quotes. "30 years old, lives in NYC" is a single field.
• Quote in a value. Doubled. "says ""hello""" decodes to says "hello".
• Newline in a value. Wrapped in quotes; the parser keeps reading until the closing quote.

A parser that splits on , and \n without state-tracking gets all three of these wrong. Real CSV parsing is a small state machine, not a regex.

Output shape variants

The tool above produces the array-of-objects form.

Common pitfalls

• BOM bytes at the start of the file. A UTF-8 BOM (EF BB BF) before the first header looks invisible but makes the first column name id instead of id. Strip BOMs before parsing.
• Inconsistent quote handling. Some rows quote, some don’t. The parser should accept both; the tool above does.
• Mismatched column counts. A row with fewer columns than the header — what should the missing fields be? null? Empty string? The tool above fills missing fields with an empty string and drops cells beyond the last header column, without a warning — check row lengths first if your data is ragged.
• Locale numbers. A column that contains 1,234.56 in US locale is the number 1234.56. In European locales the same number is written 1.234,56. CSV parsers don’t know your locale; type coercion of these to numbers will fail or produce wrong results.
• Encoding issues. Latin-1 CSV opened as UTF-8 produces mojibake on accented characters. Decode the file in its actual encoding before parsing.

For other CSV conversions, see CSV to TSV, CSV to Markdown table. For the inverse direction, JSON to CSV.