How to use
Pick the direction (CSV → JSON or JSON → CSV), paste your data on the left, and the converted result appears on the right. The delimiter selector covers comma, tab, semicolon, and pipe — semicolon for European Excel exports, tab for spreadsheet copy / paste, pipe for legacy mainframe dumps. The Has-header checkbox tells the parser whether the first row names the columns; turn it off for headless data. CSV → JSON has an extra "As objects" toggle: on emits `[{"col": "val"}]`, off emits `[["val", ...]]` (the raw row matrix).
Reach for this when shuttling data between tools that prefer different formats — exporting a DB query result as CSV but needing JSON for an API call, taking a spreadsheet someone shared and feeding it to a script, or reshaping a JSON log dump for Excel. The parser implements RFC 4180 properly: quoted fields can contain commas, double-quote-escapes, and even embedded newlines. Everything runs in the browser, so customer lists or internal data stay on your machine.
Examples
CSV with quoted commas → JSON
Input
name,age,city
Alice,30,Seoul
Bob,25,"Tokyo, Shibuya"
Carol,35,New York
Output
[
{ "name": "Alice", "age": "30", "city": "Seoul" },
{ "name": "Bob", "age": "25", "city": "Tokyo, Shibuya" },
{ "name": "Carol", "age": "35", "city": "New York" }
]The comma inside `"Tokyo, Shibuya"` survives because the field is quoted. Note that `age` lands as `"30"` (string) — CSV has no type system, so every cell is a string in the JSON output. If you need numbers, post-process with `JSON.parse` of each cell or run the result through a typing step.
JSON array of objects → CSV (union of keys)
Input
[
{"name":"Alice","age":30,"city":"Seoul"},
{"name":"Bob","age":25,"country":"JP"},
{"name":"Carol","city":"NYC","country":"US"}
]Output
name,age,city,country
Alice,30,Seoul,
Bob,25,,JP
Carol,,NYC,US
The header is the union of keys from every row in first-seen order — `name`, `age`, `city` from row 1, then `country` appended when row 2 introduces it. Missing values become empty cells. This matters when JSON rows have inconsistent shape (a common API export pattern).
CSV with embedded newlines (RFC 4180)
Input
id,note
1,"Line one
Line two"
2,"Single line"
Output
[
{ "id": "1", "note": "Line one\nLine two" },
{ "id": "2", "note": "Single line" }
]A newline inside double quotes is part of the cell, not a row separator — RFC 4180 §2.6. Most spreadsheets emit this when a cell contains multi-line text. Some hand-rolled CSV parsers treat every `\n` as a row break and silently mangle the data; the RFC 4180 parser here keeps the structure intact.
FAQ
Why are numbers in my CSV showing up as strings in the JSON?
CSV is untyped — every cell is bytes between delimiters, with no number / boolean / null distinction. Auto-typing on the parse side is dangerous because heuristics misclassify legitimate strings: `"01234"` is a US zip code that loses its leading zero if treated as a number, `"NaN"` is a country abbreviation that becomes a special value, and `"007"` is a username that becomes 7. The converter keeps everything as strings to avoid silent corruption; cast explicitly in the consuming code.
Why does Excel break my UTF-8 CSV?
Excel on Windows reads CSV as the system codepage (usually Windows-1252 or Shift-JIS) unless the file starts with a UTF-8 BOM (`EF BB BF`). Korean and Japanese text without a BOM shows as mojibake. Three workarounds: save with BOM, open via Data → From Text / CSV (which prompts for encoding), or rename the file to `.txt` so Excel runs the import wizard. Mac Excel has handled UTF-8 directly since 2016. The converter writes UTF-8 without a BOM by default — if Excel is the target, prepend the BOM after copying.
My CSV uses semicolon, not comma — what gives?
European locales (German, French, Italian, Spanish) use comma as the decimal separator, so spreadsheets emit semicolons to avoid clashes with numbers like `1,5`. Switch the delimiter to `;` and the parser handles it identically. Tabs are also common — copy-pasting from Excel or Google Sheets often produces tab-separated data even though the menu says "CSV". The Excel CSV export uses whatever the user's locale lists as the "List separator" in regional settings.
What happens with nested objects when going JSON → CSV?
CSV is flat — every cell is a string. Nested objects and arrays get stringified into JSON inside the cell: `{"a": 1}` becomes the literal text `{"a":1}` in that column. This round-trips but is not what spreadsheet users expect. If you have nested data and need real columns, flatten the JSON first (e.g., `address.city` → `address_city` column) using a tool like `jq 'paths(scalars)'` or a library such as `flat`.
CSV → JSON, can I get rows as arrays instead of objects?
Yes — turn off the "As objects" checkbox. The output becomes `[[ "Alice", "30", "Seoul" ], ...]`, a matrix of strings preserving the original column order and not requiring header names. Use this when downstream code processes by position (`row[0]`, `row[1]`) rather than by key, or when the CSV has no header row at all.
Is there a row count limit?
No hard cap, but parsing happens synchronously in the browser. Files past a few hundred thousand rows freeze the page briefly during conversion. For datasets bigger than that, prefer a CLI tool like `xsv`, `miller`, or a `pandas.read_csv` script — they stream and use proper memory layout. A million-row CSV is well outside the design point of any browser-only tool.
Related concepts
CSV (Comma-Separated Values) is one of the oldest data formats still in heavy use — first standardized informally in the 1970s, eventually formalized as RFC 4180 in 2005. The spec is short: rows are newline-separated, fields are comma-separated, double-quote a field to allow commas / newlines / quote characters inside, and escape an inner double quote as `""`. Despite the "Comma" in the name, real-world CSV files use whatever delimiter the producing locale considers natural — semicolon in much of Europe, tab in spreadsheet copy / paste, pipe in legacy mainframe exports — and dozens of edge cases break interop.
The biggest semantic gap is **typing**. CSV has no notion of number, boolean, or null — every cell is bytes. The same `0123` could be a string code or a partial integer, `true` could be a string or a boolean. Different consumers guess differently: Excel auto-types aggressively (and silently corrupts), Python `pandas` heuristically picks a column dtype, this converter keeps everything as strings. JSON has the opposite property — every value carries an explicit type. Converting JSON → CSV throws type information away; CSV → JSON has to choose between guessing and pushing the typing problem to the consumer.
Three adjacent formats fit different points on the spectrum. **TSV (Tab-Separated Values)** is CSV with a fixed delimiter and is the de facto format for spreadsheet copy / paste — fewer quoting headaches because tabs are rare in real text. **JSON Lines (NDJSON)** writes one JSON object per line, combining JSON's typing with the streamable line-oriented structure of CSV — popular in log shippers, ML datasets, and `jq -c` output. **Parquet** is a columnar binary format for actual scale (millions of rows up); it preserves types, supports schema evolution, and beats CSV by 10× in storage and read speed. CSV stays relevant because of universal compatibility, not because it is the right choice on its own merits.
