CSV to JSON
Turn a pasted table into JSON, with the separator and the header row found for you.
Result
Start typing and the result appears here. No button needed.
CSV to JSON, without the extra steps.
Paste a table and get JSON back as you type. The separator is worked out from the rows themselves — comma, semicolon, tab or pipe — and named, so a semicolon export from a European spreadsheet does not arrive as one column per row. Quoting is read properly: a comma or a line break inside a quoted field stays part of that value instead of splitting it. The first row is used as the column names only when it looks like names rather than data, values that look like numbers become numbers unless doing so would destroy them, and every column is listed with how many records actually filled it in.
How to use this tool
- 1Paste the rows, or open a .csv file. The JSON appears as you paste.
- 2Check the separator it found and whether the first row was read as column names — change either if it guessed wrong.
- 3Decide whether numbers and true/false become JSON types, then copy the JSON or download it.
When CSV to JSON is the right tool
- A colleague sends an export from a German or French copy of Excel, where the separator is a semicolon because the comma is already the decimal point.
- A product feed has a description field with commas and a line break inside the quotes, and splitting on commas turns one record into four.
- A membership list keys on IDs like 01234 and phone numbers like +441632960961, both of which a careless converter turns into different numbers.
- The rows are the output of a terminal command with no header line at all, and the first record must not be eaten as column names.
- A hand-edited file has one row with an extra unescaped comma, and you need to know which row rather than getting a silently shifted record.
The separator is worked out, then named
Comma, semicolon, tab and pipe are each tried against the first twenty rows, and the one that gives the most rows the same number of columns wins. That is the signal worth trusting: parsed with the wrong character, every line comes back as a single value, which is consistent but not a table, so a one-column result scores nothing. Whichever it settled on is named beside the control rather than assumed, and you can override it — a file whose descriptions are full of semicolons is the case where a guess can go wrong.
Quotes are read, not stripped
A quoted field can contain the separator, a line break, and doubled quotes, and that is the entire reason splitting on commas is not good enough. This reads the file as a state machine the way RFC 4180 describes, so "Red, large" is one value and a paragraph inside quotes stays one value across the lines it spans. Fields that contained a line break are counted, because a record that quietly spans three lines is the thing you most want confirmed before handing the JSON to anything else.
A number is only a number when nothing is lost
Turning digits into JSON numbers is right for a price and wrong for an identifier, so the rule is conservative: a leading zero, a leading plus, a thousands separator, or more digits than a JSON number holds exactly all keep the value as text. 01234 stays 01234 and +441632960961 keeps its country code, while 42 and 19.99 become numbers and true and false become booleans. The page counts what it converted and what it deliberately did not, and All text switches the whole thing off.
Nothing in the file is dropped to make the JSON tidy
Two columns called id cannot both be keys of one object, so the second becomes id_2 rather than overwriting the first. A row with more values than the header has columns keeps the extras under field_6, field_7, and is reported, because that row has an unquoted separator in it somewhere. A row that stops early simply lacks those keys instead of gaining empty strings. Every column is listed with how many records filled it in, so a field present in three rows of forty is visible before you send the file.
A few quick answers.
No. Each candidate separator is tried against the first twenty rows and the one that gives the most consistent number of columns wins, which is the reliable signal — the wrong separator leaves every row as a single value. The separator it settled on is named above the result, and you can override it if the guess is wrong for a file where a description happens to contain more semicolons than the file has fields.
Yes. A value like 01234 or +441632960961 is an identifier written in digits, and turning it into a JSON number would silently drop the zero or the plus, so those stay strings and the page counts how many it kept. The same applies to integers longer than a JSON number can hold exactly. If you would rather nothing at all was converted, choose All text and every cell comes back as a string.
Then it is kept. The first row is only used as names when every cell is non-empty and none of them is a number or true/false — so the output of a cut or a database dump with no header comes back as a list of values per row, with nothing eaten. You can force either reading with the First row control if your file is the exception.
It uses the row itself. A header row has a name in every cell and nothing in it that is a number or true/false — so id,name,city is names and 2024,14,9 is a record. When it reads as data, every row comes back as a list of values and nothing is consumed, which is what you want for the output of a cut or a database dump. Both readings can be forced with the First row control, and the page says which one it took.
It stays an empty string. A CSV has no way to distinguish an empty string from a null, so inventing null would be making something up about the file. The one case that is different is a row that stops before the last column: those keys are left out of the record altogether rather than filled in, since the file genuinely does not say anything about them, and the count under each column name shows you how many records carried it.
Yes — tab is one of the four separators it tries, and a .tsv opens the same way as a .csv. A file copied straight out of a spreadsheet and pasted here is usually tab separated, which is why the detection matters: the same paste would come back as one long value per row if the comma were assumed. Pipe-delimited exports from older database tools work too.
No. The parsing runs in this page, in your browser, and nothing is sent to a server — which is the part that matters when the table is a customer list or a payroll export. Opening a file reads it locally into the box; the JSON you download is generated on your own machine. You can disconnect from the network and the tool keeps working.