CSV to JSON Converter

Yes. The parser follows RFC 4180 quoting rules: a field wrapped in double quotes can contain commas, quotes, or embedded line breaks, and a literal quote inside it is written as two double quotes (""), which the converter un-escapes automatically. A comma outside quotes is always a column separator, so "Doe, John" parses as a single field containing a comma rather than splitting into two fields — the same rule Excel and Google Sheets use when they export quoted CSV.

The later column silently overwrites the earlier one. Each row becomes a single JSON object keyed by header name, and JavaScript object keys can't repeat, so if your source file has two columns both labeled "Notes" (common after a spreadsheet merge or export bug), only the second column's values survive in the JSON — the first column's data is dropped without a warning. Rename duplicate headers before pasting if you need to keep both columns.

This page is comma-only, matching the plain "CSV to JSON" use case most people search for. If your file is semicolon- or tab-delimited — common in European locales where the comma is used as the decimal separator, or in files exported from database tools — use the full CSV/JSON converter, which auto-detects the delimiter or lets you choose comma, semicolon, tab, or pipe explicitly.

Rows are matched to headers by position, not by count, and nothing here throws an error. A short row (fewer fields than headers) fills the missing trailing values with null; a long row (more fields than headers) has its extra values silently discarded, since only as many fields as there are headers get read. Ragged CSV — often caused by a stray or missing delimiter partway through a file — won't be flagged, so check row lengths first if exact column alignment matters.

This happens because the converter infers types from the text pattern of each cell, and a plain digit string like 02138 or 4025 matches the integer pattern regardless of what it's supposed to represent. Once it's treated as a number, parseInt("02138") returns 2138 — the leading zero is gone, because JSON numbers have no concept of "padded" digits the way a string does. CSV itself can't flag a field as "keep this as text": RFC 4180 quoting only controls how commas, quotes, and line breaks are escaped, not the data type of what's inside the quotes, so a quoted "02138" and an unquoted 02138 parse identically. If you're converting ZIP codes, phone numbers, SKUs, or account numbers, use the full CSV/JSON converter tool and switch off type inference so every column is preserved as a string, then re-add typing selectively where you actually want numbers.

The most common case is moving a spreadsheet export into something that only speaks JSON. A marketing team exports a CSV of leads from a CRM and needs to POST them to a webhook or a Zapier/Make automation that expects a JSON body. A backend developer has a CSV of product data from a vendor and needs to bulk-insert it into MongoDB or Firestore, both of which store JSON-like documents rather than rows and columns. A QA engineer takes a spreadsheet of test cases and turns it into a JSON fixture file consumed by a test runner. In each case the source of truth is tabular (a spreadsheet, a database export, a CRM download), but the destination — an API, a document store, a test harness — only accepts JSON, so a fast, accurate one-off conversion saves writing a parser for a task done once or twice a month.

CSV predates any formal specification by decades — spreadsheet and mainframe tools were writing comma-delimited text files since the 1970s, each with its own quirks around quoting and line endings. RFC 4180, published by Y. Shafranovich in 2005, documents the common conventions (CRLF line endings, optional double-quote wrapping, doubled quotes for escaping) but is explicitly informational, not a binding standard. In practice, "CSV" still varies: Excel in some European locales exports semicolon-delimited files because the comma is the decimal separator there, some tools use bare LF instead of CRLF, and BOM-prefixed UTF-8 is common from Windows exports. JSON, by contrast, has genuine standards behind it — ECMA-404 and RFC 8259 — which is part of why it parses identically everywhere and CSV parsers still have to guess at dialect.

No — this is a common misconception. CSV rows and columns only ever produce a flat JSON array of flat objects; there's no way to express nesting in CSV, so this converter (or any CSV-to-JSON tool) can't output nested objects or arrays no matter how the data is organized. The type of each value isn't fixed either: because CSV stores everything as text, "42" could mean the number 42 or the string "42" depending on context, and different tools infer types with different rules. This converter's rules (true/false for booleans, digit patterns for numbers, empty/null/n-a for null) are one reasonable set of defaults, not a guarantee that matches every other CSV parser you might compare output against, including spreadsheet software's own CSV import.

The header row supplies the JSON key names directly, character for character, including spaces, punctuation, or emoji if your source file has them — JSON keys are just strings, so almost anything is valid. The one exception is a completely blank header cell: rather than produce a key with no name, the converter falls back to a placeholder like column1, column2, matching the cell's position in the row, so every value still ends up somewhere in the output object, just under a generic name instead of the missing label. If you want cleaner, code-friendly key names — no spaces, consistent casing, no special characters that would need bracket notation in JavaScript — it's worth renaming the header row in your source spreadsheet before pasting, since the converter maps headers as-is rather than normalizing or sanitizing them for you.