CSV to JSON Converter

What is CSV to JSON conversion?

A CSV to JSON converter reads a comma-separated file and turns each row into a JSON object, using the header row as the keys. The columns become object keys, each row becomes one array element, and the result is something a web page, a script, or an API can consume directly instead of parsing text by hand. Whether the source was a spreadsheet, a database export, or a log file someone saved with a .csv extension, the shape on the way in is always rows and columns, and the shape on the way out is always the same: an array, one object per row.

CSV is what spreadsheets and databases export by default; JSON is what nearly everything downstream actually wants. A product export, a mailing list, a table pulled from a database console — all land as CSV, and all eventually need to become an array of objects for a script, a test fixture, or an API request body. The conversion looks trivial until the file has a comma inside an address field, or comes from a country where the decimal separator is a comma, at which point splitting on commas quietly produces the wrong number of fields.

How to use it

1. Paste the CSV. Drop the raw text into the box. The tool auto-detects the delimiter — comma, semicolon, tab, or pipe — and the picker starts on whatever it found, though you can override it if the guess is wrong.
2. Set the header and number options. Leave the header checkbox on if the top row holds column names, and decide whether to turn on number conversion — it is off by default, because not everything that looks like a number is one. Pick 2 spaces, 4 spaces, tab, or minified for the output indent.
3. Read the JSON and the warnings. The output appears with its row and column count, plus flags for any row whose field count does not match the header, any unterminated quote, and any number too large for a JavaScript double to hold exactly.

Why parsing CSV is harder than it looks

There is no CSV standard. RFC 4180 was written in 2005 as a description of what people were already doing, not a specification anyone is obliged to follow, and it shows: much of Europe uses a semicolon instead of a comma, because the comma is already spoken for as the decimal separator, and tab- and pipe-delimited files show up regularly too. Every CSV file you are handed is really a guess about which dialect produced it, which is why the delimiter here is a picker rather than an assumption baked into the code. A file that has passed through a spreadsheet often carries a byte order mark at the very start too, and if nothing strips it, it survives into the first header name — so a column that looks like id on screen is not actually equal to the string id. This tool strips it before parsing starts.

Splitting each line on commas, which is what a lot of one-line parsers do, corrupts the first file that contains an address, a comment, or a quoted quote. In a,"x,y",b the quoted field has a comma in it and the row is still three fields, not four; with a real line break inside the quotes, the whole thing is one field spanning two lines of text, which a naive split-on-newline reads as two separate rows. This tool runs a state machine over the text character by character, tracking whether it is inside a quoted field, so a doubled quote correctly comes out as one real quote mark rather than two stray characters — and the same state machine treats CRLF, LF, and a bare CR as equally valid row endings, since all three show up in real files. It was differential-tested against Papa Parse, an established CSV library installed only for the comparison and removed afterward: 18 sample documents, agreeing on every one, plus 2,000 randomly generated tables round-tripped through the tool's own quoting and read back identical every time.

Delimiter detection works the same way, by consistency rather than by counting characters. A frequency count would misread a;b;"x, y";c as comma-delimited, because the quoted field happens to contain one comma while the real delimiter appears three times outside quotes. This tool instead checks which candidate splits every row into the same number of fields and picks that one, which is why that exact input is correctly detected as semicolon-delimited.

The harder problem is numbers, and it is why conversion is opt-in rather than automatic. 007 is a postcode or an order id, not the number 7; a phone number written with a plus and spaces is not arithmetic; a trailing dot is not valid JSON at all. So even with number conversion turned on, the tool only touches values written exactly the way JSON writes numbers, leaving leading zeros, plus signs, and trailing dots as strings. The bigger risk is precision: parsing the id 12345678901234567890 with the browser's own JSON parser gives back 12345678901234567000, because a double only holds about 17 significant digits and silently rewrites the last four. This tool keeps a 20-digit id as written all the way through the conversion and flags it, because the next program to touch that JSON may not be so careful.

Honest limitations

Two things about CSV are unfixable, not just unimplemented. A trailing empty row is indistinguishable from a trailing newline at the end of the file — there is no way to know which one a given file means. And once a value has been written out, an empty field and a quoted empty string look identical on disk, so a round trip through CSV can lose that distinction even when nothing went wrong.

Malformed quoting has no correct answer, only a documented choice. RFC 4180 does not define what happens when a quote closes in the middle of a field, so readers disagree: given a,"b"c,d this tool ends the quoted section where the quote closes and returns three fields, while Papa Parse keeps consuming and returns two. Neither is wrong, because there is no rule to be right or wrong against — the tool just tells you what it decided rather than pretending the decision was inevitable.

Turning numbers on is a judgement call you are making, not a fact the tool is discovering, so it is worth checking the warnings rather than trusting the checkbox blindly. And once the JSON leaves this tool its job is done: if the original file gets opened in a spreadsheet afterwards, that program can still reinterpret a value on its own terms, entirely outside this tool's control. Going the other way is the JSON to CSV converter, which has its own set of decisions to make.

Why is it free?

This runs entirely in your browser — the CSV never leaves your device, because there is no server for it to travel to. That is a genuine property of how the tool is built, not a policy that could quietly change: there is no account, no watermark, and nothing to upload in the first place. The parsing, the delimiter detection, the number checks, all of it runs as JavaScript in the tab that is already open.

It matters for exactly the files people hesitate to paste into a random web form: a customer export, a database dump, anything with real names and addresses in it. Since the conversion happens on your machine, that file never crosses the network, and there is nothing to charge for on a process that never touches a server.