ToolActToolAct

CSV to JSON Converter

Upload a CSV file or paste data to convert to JSON format

Drop CSV file here, or click to select

What is CSV to JSON?

CSV to JSON is an online data format conversion tool that converts CSV (Comma-Separated Values) data into JSON (JavaScript Object Notation) format.

CSV is a common tabular data format widely used in spreadsheets and database exports. JSON is the most popular data exchange format in modern web applications, known for its clear structure and easy parsing.

With this tool, you can quickly convert CSV data into JSON arrays or objects for use in programming and data processing.

CSV to JSON looks simple, but delimiter choice, quotes, line breaks inside fields, empty values, and character encoding determine whether the output is reliable. Column headers usually become JSON keys, so duplicate or unclear names should be cleaned first. For APIs, imports, analytics, or migrations, the converted data should still be checked for types, number formats, dates, null rules, and rows that did not match the expected column count.

How to Use

How to use

  1. Paste or type CSV data in the left input panel
  2. Select the appropriate delimiter (comma is default)
  3. Choose whether to use the first row as field names
  4. The right panel will automatically generate the JSON result

CSV Parsing Notes

  • Check delimiter, quote handling, and header-row settings before trusting the JSON output.
  • Large CSV files can contain blank rows, embedded commas, or line breaks inside quoted cells; preview a few rows after conversion.

Use Cases

Convert uploaded CSV or TSV files into JSON arraysDrop or select a .csv, .tsv, or .txt file, choose comma, tab, semicolon, or pipe delimiter, and decide whether the first row should become object keys or the output should stay as arrays. The file is read in the browser with FileReader, parsed locally with a streaming tokenizer, and never uploaded, so customer or internal exports never leave the device.
Preview row and field counts before using the JSONUse the displayed file name, row count, field count, and highlighted JSON output to catch delimiter mistakes, missing headers, or empty rows before copying into mocks or scripts. This works well as a controlled intermediate step: paste the output into the real destination and verify that the receiving system interprets it the same way.
Handle simple quoted CSV without leaving the browserThe parser supports quoted fields, escaped doubled quotes, and the four common delimiters, making it suitable for small exports and test data. Files are processed entirely in the browser memory, so even sensitive HR, finance, or staging snapshots can be reshaped without sending the data over the network.
Preserve type info when sending JSON to a typed APIAfter conversion, scan the output for fields that should be numbers, booleans, dates, or nulls instead of strings, then post-process the array before sending to REST or GraphQL endpoints. CSV has no native types, so a quick visual sweep of the first few rows is usually enough to catch quoted IDs and zero-padded codes.
Spot malformed rows before pushing to mocks or fixturesUse the row/field count and parse errors to flag lines that do not match the expected column count, then fix the source CSV rather than letting bad rows leak into mock JSON. The preview pane stops on the first inconsistent row so you can correct the delimiter or add a missing quote before re-running.

Technical Principle

CSV parsing follows the IETF RFC 4180 grammar: each record terminates with CRLF (some dialects accept LF or CR), each record contains fields separated by a delimiter (comma in RFC, but TSV, semicolon, and pipe are widespread variants), and any field that contains the delimiter, a CR, an LF, or a double-quote MUST be wrapped in double quotes with internal double-quotes escaped by doubling (Hello "world" becomes "Hello ""world"""). The parser in this page is a state machine with four states - field_start, in_unquoted, in_quoted, after_quote - and processes the input in a single O(n) pass over the character stream, so a 10 MB CSV with 100,000 rows finishes in well under a second on a typical laptop without ever allocating an intermediate token array per row. Encoding requires explicit handling: a UTF-8 BOM (EF BB BF) at the start of the file is stripped before parsing, otherwise the first header name would silently begin with the invisible U+FEFF code point and downstream JSON.parse equality checks would fail. Excel exports on Windows still emit CRLF and often UTF-8 with BOM, while macOS Numbers and most Unix tools default to LF without BOM. European spreadsheets commonly export semicolon-delimited files because the comma is a decimal separator in many locales (49,90 EUR rather than 49.90), which is why the delimiter selector defaults to comma but exposes tab, semicolon, and pipe as first-class choices. The first-row-as-header toggle changes the output shape from an array of objects (header keys -> string values) to an array of arrays, matching the two common ingestion patterns for downstream code. Field values are emitted as strings, not as inferred types - CSV has no schema, so 01234 (a zero-padded ID), 1e10 (a phone-number-looking string that JSON.parse would coerce to a number), and 2024-13-45 (a malformed date) all stay verbatim. This is intentional: a downstream typed API can apply zod, Joi, or a hand-rolled coercion layer with explicit rules, but it cannot recover a leading zero that the converter has already dropped. Output is generated via JSON.stringify(rows, null, 2) and rendered through a syntax highlighter; the source CSV is read with FileReader.readAsText() on a Blob, never uploaded to a backend, so HR exports, finance ledgers, and customer lists can be reshaped without leaving the browser session.

  • RFC 4180 grammar: fields with delimiter/CR/LF/" must be quoted; internal quotes doubled as "".
  • Single-pass O(n) state machine with states: field_start, in_unquoted, in_quoted, after_quote.
  • UTF-8 BOM (EF BB BF / U+FEFF) is stripped at file start to keep header keys clean.
  • European spreadsheets often use ; as delimiter because , is the decimal mark in locale settings.
  • First-row-as-header toggles output between Array<Record<string,string>> and Array<Array<string>>.
  • All field values remain strings; leading-zero IDs like 01234 survive only because no type inference runs.
  • FileReader.readAsText() processes the Blob locally; nothing is uploaded - safe for HR/finance/staging exports.

Examples

Basic CSV with header row -> JSON array of objects

CSV input:
name,age,city
Alice,28,New York
Bob,35,London
Carol,42,Tokyo

JSON output:
[
  { "name": "Alice", "age": "28", "city": "New York" },
  { "name": "Bob",   "age": "35", "city": "London"   },
  { "name": "Carol", "age": "42", "city": "Tokyo"    }
]

Quoted fields with embedded commas

CSV input:
id,product,description
1,"Notebook, A5","Hard cover, 200 pages"
2,Pen,"Black ink, 0.5mm"

JSON output:
[
  { "id": "1", "product": "Notebook, A5", "description": "Hard cover, 200 pages" },
  { "id": "2", "product": "Pen",          "description": "Black ink, 0.5mm" }
]

TSV (tab-delimited) without header

TSV input (delimiter = Tab, header off):
101	Alice	98.5
102	Bob	87.0
103	Carol	92.3

JSON output:
[
  ["101", "Alice", "98.5"],
  ["102", "Bob",   "87.0"],
  ["103", "Carol", "92.3"]
]

Semicolon delimiter (European spreadsheet exports)

CSV input (delimiter = ;):
product;price_eur;stock
Keyboard;49,90;120
Mouse;19,90;345

JSON output:
[
  { "product": "Keyboard", "price_eur": "49,90", "stock": "120" },
  { "product": "Mouse",    "price_eur": "19,90", "stock": "345" }
]
Note: numbers stay as strings - cast in your downstream code.

FAQ

What CSV variants are supported?

Standard RFC 4180 CSV: comma separator, double-quote field quoting, doubled-double-quotes for escaping. Tab-separated (TSV) and semicolon-separated CSVs work by changing the separator. Different line endings (LF/CRLF/CR) are handled automatically.

How are headers handled?

If you enable 'first row is header', the parser uses each header cell as the JSON key for that column - producing an array of objects. With headers off, the parser produces an array of arrays. Empty header cells get a numeric placeholder key.

How are types inferred?

By default everything is a string. Toggle 'auto type' to attempt number, boolean (true/false), and null parsing. Numbers with leading zeros (00123, 0042) become strings to avoid losing the prefix - use this for IDs and zip codes.

What if a field contains a comma or a newline?

Wrap the field in double quotes: "Smith, John" or "line one\nline two". Embedded double quotes are doubled: "He said ""hi""". The parser handles all of these; if a row is broken, the cause is usually unbalanced quotes.

How is the conversion handled - locally or on a server?

Locally. Parsing runs in your browser using JavaScript. Pasted CSV does not leave the page. Large files may slow the browser down; if a paste exceeds tens of MB, split it before processing.

Does it preserve column order?

Yes - each row becomes a JSON object whose key order matches the CSV header order, and JSON.stringify in modern engines preserves insertion order. If your downstream tool reads JSON without insertion-order preservation, that is its limitation.

How do I handle dates?

Dates remain as strings. Auto-typing does not parse arbitrary date formats because there is no unambiguous standard (1/2/2024 is January 2 in the US and February 1 in Europe). Convert dates to ISO 8601 (YYYY-MM-DD) before importing if you need native Date objects downstream.