CSV to JSON Converter — Both Directions
Convert CSV to JSON and back with correct RFC 4180 quoting, custom delimiters, header control and optional type inference.
Paste your CSV here, or drag a file…
Drag & drop a file, or paste content above
Output will appear here
CSV is harder than it looks
"Split on commas" works until it does not, and it stops working almost immediately on real data.
RFC 4180 describes the format, though it postdates the format's widespread use and plenty of producers ignore it. The rules that matter:
- A field containing a comma, a double quote or a newline must be wrapped in double quotes.
- A literal double quote inside a quoted field is escaped by doubling it:
"". - A quoted field may contain newlines. This is the rule that breaks line-by-line parsing — a single record can span many physical lines.
- Records are separated by CRLF, though most parsers accept LF.
So She said "hi", then left is written as "She said ""hi"", then left". Any parser that splits on commas produces three broken fields from that single value.
Beyond the spec, real CSV files bring their own problems: a byte order mark at the start (Excel adds one), semicolon delimiters in locales where the comma is the decimal separator, inconsistent column counts between rows, and encodings that are not UTF-8.
CSV problems you will hit with real files
Leading zeros disappear — 00123 becomes 123
Cause:Type inference converting a string of digits to a number. This destroys postcodes, product codes, phone numbers and any zero-padded identifier.
Fix:Turn type inference off so every field stays a string, then convert only the columns you know are numeric.
A long number becomes 1.23457E+14
Cause:Excel converts long digit strings to floats and displays them in scientific notation — and, worse, saves them that way. Credit card numbers and large IDs are silently destroyed.
Fix:Never round-trip identifiers through Excel. If you must, format the column as Text before importing rather than after.
Fields split in the wrong places
Cause:The file uses semicolons, not commas. In locales where the comma is the decimal separator, Excel exports semicolon-delimited files and still calls them CSV.
Fix:Set the delimiter explicitly. Tab-separated files have the same issue and are the safest choice for data containing commas.
The first column header has a stray character
Cause:A UTF-8 byte order mark (EF BB BF) at the start of the file, which Excel writes by default.
Fix:Strip the BOM before parsing. A header that looks like "id" but never matches "id" in code is almost always this.
Row count is wrong — fewer rows than expected
Cause:Quoted fields containing newlines, being counted as separate records by a line-based reader.
Fix:Use a real CSV parser rather than splitting on \n. This is the single most common cause of silently truncated imports.
Accented characters become mojibake
Cause:The file is Windows-1252 or Latin-1, being read as UTF-8 — or the reverse. Excel on Windows still defaults to the system code page for CSV export.
Fix:Export as "CSV UTF-8" from Excel. If you are receiving the file, detect or ask for the encoding rather than assuming.
Nesting: the direction that does not round-trip cleanly
JSON is a tree; CSV is a grid. Converting a grid to a tree is mechanical, but converting a tree to a grid requires a decision about how to flatten it, and some trees cannot be flattened without losing information.
Nested objects flatten predictably by joining keys: {"user": {"id": 7}} becomes a column named user.id. Deterministic and fully reversible.
Arrays are the problem. If every row has exactly three tags, you can produce tags.0, tags.1, tags.2. If the count varies — which it usually does — you either create a very wide sparse table sized to the longest row, or you serialise the array into one cell as a delimited string and accept that it is no longer structured.
There is no universally right answer, which is why this needs a human decision. If the array is genuinely a list of independent things, the relational answer is usually a second CSV file with a foreign key, not a wider first one.
About
The CSV ⇄ JSON Converter transforms tabular CSV data into structured JSON arrays and vice versa. It auto-detects headers from the first row, handles quoted fields, and lets you choose between array-of-objects and array-of-arrays output formats. The reverse direction produces properly quoted CSV from a JSON array.
How to use
- 1 Paste your CSV data and click Convert to JSON to get a JSON array.
- 2 For JSON → CSV, paste a JSON array of objects and click Convert to CSV.
- 3 Adjust delimiter settings if your CSV uses semicolons or tabs.
- 4 Copy or download the result.
- Does the CSV to JSON converter handle quoted fields with commas inside them?
- Yes. The parser correctly handles RFC 4180-compliant CSV, including fields enclosed in double quotes that contain commas, newlines, or other special characters. Fields like "Smith, John" are treated as a single value, not split at the internal comma.
- What JSON format does the converter produce?
- By default the converter produces an array of objects, where each object represents one CSV row and its keys are the column headers from the first row. You can also choose array-of-arrays format (no headers used as keys) for when you need a simple nested array structure.
- My CSV uses semicolons instead of commas — will it still work?
- Yes. The delimiter can be changed to semicolon (;), tab (\t), or pipe (|) to handle European-style CSV files and TSV (tab-separated values) files. Select the correct delimiter before converting and the parser will use it to split fields.