CSV to JSON Converter

The CSV to JSON converter reads comma-separated (or semicolon-, tab-, or pipe-separated) text and turns it into a structured JavaScript Object Notation document. The simple cases are trivial; the non-simple cases are where naive converters fall over, and the failure is silent. A field like "Smith, John" is one logical cell, not two. A field like "line one\nline two" spans two physical lines. A field like "He said ""hi""" contains a literal double quote encoded as two characters back to back. None of those cases survive text.split(','). The whole job of a correct CSV to JSON tool is to honour the rules in RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files, the de-facto CSV specification since 2005. The output is then serialised with JSON.stringify so it conforms to ECMA-404 and RFC 8259, the JSON Data Interchange Format.

What CSV actually is (and why it is deceptively hard)

CSV is a text format where each line is a record and each record contains the same number of comma-separated fields, with an optional header row giving the field names. In its simplest form the format is self-explanatory and people happily use it in spreadsheets, log files, and machine-to-machine data feeds. The format gets hard the moment a field can legitimately contain the delimiter, a quote, or a newline. RFC 4180 solves this with three rules: (1) a field that contains the delimiter, a quote, or a newline must be wrapped in double quotes; (2) inside such a field, a literal double quote is encoded as two consecutive double quotes; (3) everything else, including spaces, is preserved literally. The grammar is small but the consequences are wide. Most off-the-shelf "CSV to JSON" tools in the wild, and a surprising number of well-known libraries, implement a fast path that does not honour those rules and then quietly produce wrong JSON for any input that triggers them. This converter uses a character-scanning state machine, not split, so the correct cases stay correct.

How to use the converter

1. Paste CSV into the left pane, or click one of the four quick samples (simple comma CSV; quotes/commas/newlines; European semicolon CSV; type-coercion traps).
2. Pick the delimiter in the dropdown. The default is comma, which matches RFC 4180 and most English-language exports. Semicolon is the common European choice where the decimal separator is already a comma. Tab and pipe are the usual fallbacks when the data is from a copy-paste out of a SQL client or a Confluence table.
3. Toggle First row is a header. On (default) produces an array of objects keyed by the header. Off produces an array of arrays, where each inner array is one record.
4. Toggle Trim whitespace when the data came out of a source that pads fields (some legacy mainframe exports, some HTML table scrapers).
5. Toggle Parse numbers and booleans when you want "42" to come out as the number 42 and "true" to come out as the boolean true. Leave it off if the data should stay verbatim, that is the safe default for postal codes, phone numbers, IDs, and any other field that looks numeric but carries meaning only as a string.
6. Toggle Pretty-print for 2-space indented JSON, or switch it off for minified single-line output that is easier to paste into a request body.
7. Read the row/column counts and the output size under the result box, and click Copy JSON to put the output on the clipboard.

The right pane is read-only and updates as you type. Errors (most commonly an unterminated quoted field) show as a clear message instead of a half-parsed blob, so the tool never crashes and never silently returns wrong data.

The parser: a character-scanning state machine

The parser walks the input one character at a time, holding two pieces of state: whether it is currently inside a quoted field, and the buffer of characters that make up the current field. While it is inside a quoted field, the delimiter, CR, and LF characters are written into the buffer literally, they do not end the field and do not end the record. While it is outside a quoted field, a quote at the start of a field opens a quoted field, a delimiter ends a field, and a newline ends a record. A doubled quote inside a quoted field is decoded to a single literal quote. A UTF-8 byte order mark at the very start of the file is stripped, because Excel routinely prepends one when exporting as "CSV UTF-8" and the user did not ask for it.

This is the same algorithm described in section 2 of RFC 4180, just implemented as a single forward pass. The output of the parser is a rectangular-ish list of lists of strings, with two side tables marking which fields were quoted (used downstream for diagnostic display) and an error string if a quoted field was never closed.

The JSON stage is then a thin pass: with the header toggle on, the first row is taken as object keys, and uniqueness is enforced by appending _2, _3, … to duplicate header names so the resulting object is a valid ECMAScript object (and therefore valid JSON). With the header toggle off, the rows go through as arrays. Whitespace trimming is applied uniformly if requested. Number and boolean coercion runs on each cell, but only for cases that are unambiguous and lossless, see the type-coercion section below.

The formula, in one line

output = JSON.stringify(parseCsv(input, delimiter, hasHeader, trim, coerce))

Where parseCsv is the character state machine, coerce is a guarded regex pass that converts unambiguous numeric and boolean literals and leaves everything else as a string, and JSON.stringify produces ECMA-404 / RFC 8259 conformant output.

Worked examples

Example 1, Simple CSV with header. Input name,age,city\nAlice,30,Paris\nBob,25,Berlin with the default options (comma, header on, no trim, no coercion) produces:

[
  {"name": "Alice", "age": "30", "city": "Paris"},
  {"name": "Bob", "age": "25", "city": "Berlin"}
]

Example 2, Quoted field with an embedded comma. Input name,city\n"Smith, John",Paris\n"Doe, Jane",Berlin produces:

[
  {"name": "Smith, John", "city": "Paris"},
  {"name": "Doe, Jane", "city": "Berlin"}
]

A naive split(",") would have produced four fields per record, with "Smith and John" as separate cells. The state machine correctly recognises that the opening quote at the start of the field changes how the inside of the field is parsed.

Example 3, Escaped double quote inside a quoted field. Input id,quote\n1,"He said ""hello"" loudly" produces:

[{"id": "1", "quote": "He said \"hello\" loudly"}]

The doubled "" decodes to one literal " character, and the JSON serialiser then re-encodes that single " as \" to keep the output valid JSON.

Example 4, Quoted field containing a real newline. Input (with a literal LF inside the second field):

id,note
1,"line one
line two"

produces:

[{"id": "1", "note": "line one\nline two"}]

Example 5, European semicolon CSV with number coercion. Input stadt;einwohner\nParis;2148000\nBerlin;3645000 with delimiter ; and coercion on produces:

[
  {"stadt": "Paris", "einwohner": 2148000},
  {"stadt": "Berlin", "einwohner": 3645000}
]

Without coercion the einwohner values would come out as the strings "2148000" and "3645000".

Where CSV-to-JSON shows up

The conversion shows up everywhere structured tabular data has to cross a system boundary that speaks JSON. Four common settings: (1) API request body preparation, REST endpoints that take a JSON array of objects in the body, where the upstream data is almost always CSV; (2) data migration, moving a customer list, a product catalogue, or a transaction log from a legacy system to a new database, where the legacy export is CSV and the new seed script wants JSON; (3) config seeding, generating a small JSON config file (block lists, feature flags, env-by-env overrides) from a spreadsheet that non-engineers can edit; (4) spreadsheet → app import, exporting a Google Sheet or an Excel file to CSV, converting to JSON, and loading into a web app, a notebook, or a NoSQL store. In every one of those settings the cost of a wrong parser is silent data corruption, so the RFC 4180 rules matter.

Type-coercion pitfalls

Coercing CSV cells to native JSON types is a well-known minefield. The rule we use is: coerce only when the result is unambiguous and lossless, and stay a string in every other case. Concretely:

• Leading zeros: a cell "007" is a valid JavaScript number (7) but the leading zero is information, Bond's agent number, a US zip code, a UK phone-code prefix, an SKU. We leave it a string.
• Phone numbers: a cell "+44 20 7946 0958" contains spaces and a +. Even if it were stripped to digits, the length is information. We leave it a string.
• Dates: a cell "2024-01-15" is unambiguous, but a cell "01/15/2024" is American and a cell "15/01/2024" is European. We refuse to guess and leave it a string.
• Large integers: the JavaScript Number type is IEEE 754 double, so any integer outside [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER] (roughly ±9.007 × 10^15) silently loses precision. We leave those as strings so an ID like 9007199254740993 round-trips intact.
• Booleans: we coerce the four case-sensitive literals "true", "false", "TRUE", "FALSE". Anything else ("Yes", "Y", "1") is left a string to avoid regional ambiguity.

The default for the toggle is off, which means every cell is a string. That is the safe, lossless default and matches what most ETL scripts want on the first pass.

Regional and encoding quirks

In the United States and the United Kingdom, the comma is the field delimiter and the period is the decimal separator. In most of continental Europe, the comma is the decimal separator and the field delimiter is the semicolon. The converter lets you pick which delimiter to use, because there is no reliable way to auto-detect it from the data itself: a row of "all-commas" looks identical whether it was meant as one column or as N+1 columns. If you are not sure which delimiter your data uses, open the file in a plain-text editor and look at the first line, the character that separates the first two non-quoted values is the delimiter.

A second regional quirk is the byte order mark (BOM). Excel's "Save as CSV UTF-8" option writes three invisible bytes (EF BB BF) at the start of the file. The converter strips a leading BOM so the header row stays clean. A third quirk is line endings: RFC 4180 specifies CRLF, but Unix tools emit LF, classic Mac files emit bare CR, and Windows tools emit CRLF. The parser accepts all three.

Common mistakes

• Trusting split(','). Works for the first toy case, fails the moment a field contains a comma, a quote, or a newline. The fix is to use a real CSV parser, not a string method.
• Auto-detecting the delimiter. Tempting, but every "smart detector" gets it wrong on edge cases. Pick the delimiter explicitly.
• Coercing everything to numbers. Loses leading zeros, drops precision on big IDs, and turns "007" into 7. The safe default is "strings only" and coerce on demand.
• Stripping whitespace by default. Some data sources pad fields; most do not. Toggle trim on only when you have evidence the source pads.
• Ignoring ragged rows. A row that has fewer or more fields than the header is a real-world data problem, not a parser bug. The converter pads short rows with empty strings and names extra cells column_N so the JSON object stays well-formed.

Frequently Asked Questions

What is RFC 4180 and why does it matter for CSV to JSON?

RFC 4180 is the Internet Engineering Task Force informational specification for the comma-separated values format. It defines the three rules that make CSV a real format instead of an informal convention: fields containing the delimiter, a double quote, or a line break must be wrapped in double quotes; inside a quoted field, a literal double quote is encoded as two double quotes back to back; and the record separator is CRLF (though most modern parsers accept LF and bare CR as well). A converter that does not honour these rules will silently mis-parse any field that triggers them.

Why does my CSV file use semicolons instead of commas?

In most of continental Europe the comma is the decimal separator (a price is written 9,99 €, not 9.99 €), so a comma cannot also be the CSV field delimiter. The convention in those locales is to use the semicolon. Spreadsheets like Excel, LibreOffice Calc, and Google Sheets all honour the regional setting when exporting to CSV. If you open a file that is one long semicolon-separated line, the converter's delimiter dropdown is what you need.

Should I turn on "Parse numbers and booleans"?

Only when you are sure the column is genuinely numeric or boolean. Leave it off for zip codes, phone numbers, ID fields, and any text that happens to look like a number. The safe default is to keep every cell as a string and convert downstream in code where you have full type information and can decide on a per-column basis.

What happens to leading zeros and large integers when coercion is on?

Leading zeros (like "007") are kept as strings because the leading zero is information. Integers whose absolute value exceeds 2^53 − 1 (about 9.007 × 10^15) are also kept as strings, because JavaScript's Number type cannot represent them losslessly. This is the behaviour you want for product SKUs, government IDs, and any large numeric identifier.

What if my CSV file has an extra blank line at the end?

Blank lines between records are ignored automatically. The parser discards any record whose single field is the empty string. If the blank line is inside a quoted field, the newline is preserved as part of the field value, which matches RFC 4180 and is the right behaviour for multi-line cells.

can the CSV to JSON Converter be used for professional or commercial purposes?

yes, the CSV to JSON Converter provides mathematically correct results that are suitable for professional, commercial, and educational use. For the CSV to JSON Converter, For the CSV to JSON Converter, For high-stakes applications (medical, legal, financial), verify results with a domain expert. For the CSV to JSON Converter, the CSV to JSON Converter formulas used are well-established and validated against reference standards.

For the CSV to JSON Converter, How often are the underlying formulas updated?

For the CSV to JSON Converter, the CSV to JSON Converter formulas are based on established scientific, mathematical, or industry-standard references and rarely require updates. when standards change, the CSV to JSON Converter is updated to reflect the current authoritative source. For the CSV to JSON Converter, For the CSV to JSON Converter, Each calculator's references section lists the specific sources used.

References

• RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich, 2005. The Internet Engineering Task Force informational RFC that defines the grammar this converter implements: quoted fields, escaped double quotes, embedded newlines, and CRLF record separators.
• RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, editor, 2017. The Internet Engineering Task Force standard that defines the JSON syntax. The output of this converter is validated by JSON.stringify, which produces a string conforming to this RFC.
• ECMA-404, The JSON Data Interchange Format. 2nd edition, 2017. The Ecma International standard that defines JSON. ECMA-404 and RFC 8259 describe the same format; ECMA-404 came first and RFC 8259 is the IETF's editorial rendering of it.
• Microsoft Excel documentation, Save a workbook to CSV or PDF. Microsoft Support article describing the "CSV UTF-8" export option that adds a UTF-8 byte order mark, and the regional delimiter behaviour that switches between comma and semicolon based on the operating system's locale.
• W3C / WHATWG, Encoding Standard. The reference for how browsers and the JavaScript runtime interpret a leading byte order mark in a UTF-8 byte stream, which is why the converter strips one if present.