Convert CSV to JSON

Drop a CSV here

or paste it below — .csv, .tsv, .txt

CSV

Delimiter

Output

Convert numbers and true/false leading zeros and oversized IDs stay text Empty cells become null instead of an empty string Keep surplus fields in _extra for rows longer than the header Minify no indentation

Paste a CSV or drop a file in and get JSON back. The parser follows RFC 4180 properly, so a comma inside a quoted field stays part of the value and a line break inside a quoted field does not split the record in two. Afterwards the page tells you what it found: how many records, how many rows had the wrong number of fields, whether a BOM was stripped, and which duplicate headers had to be renamed. Nothing is uploaded.

Nothing is uploaded — the file stays on your device
No file size limit
No sign-up, no watermark
Free, with no paid tier holding anything back

How to convert CSV to JSON

Drop a .csv file into the box above, or paste the rows straight into the CSV field. Nothing is uploaded either way.
Leave the delimiter on Detect automatically unless the guess is wrong — comma, semicolon, tab and pipe are all recognised.
Choose the shape: an array of objects, which is what APIs and import tools expect, or an array of arrays if you want the raw grid.
Press Convert to JSON, then read the report underneath before you copy the result. It is the part that matters.

Why the report is the point

Every CSV to JSON converter handles a tidy file correctly; that part is a solved problem. Real files are not tidy, and the damage they cause is quiet: a column silently shifted by one, a postcode that lost its leading zero, an address split into two records. Nothing errors. You find out weeks later, from the data.

So this tool counts. After every conversion it tells you how many records it read, how many rows had the wrong number of fields, whether a byte order mark was stripped, which duplicate headers were renamed, and how many numeric-looking values it deliberately refused to turn into numbers. If none of that applies to your file, it says so. The point is that you are told either way rather than left to assume.

The four things that quietly break a conversion

In the file	What usually happens	What happens here
A line break inside a quoted field	The record is split in two; both halves are wrong and neither is flagged	Kept as one record. The page shows text lines next to record count so you can see the gap
A byte order mark at the start	The first key becomes an invisible-prefixed string nothing will match	Removed before parsing, and reported
Two columns with the same name	The second overwrites the first in the JSON object; the column disappears	Renamed to `name_2`, with every rename listed
A row with more or fewer fields than the header	Truncated or misaligned, shifting values into the wrong keys	Counted and reported; surplus fields can be kept in `_extra`

Newlines inside fields: the one that costs the most

A CSV field can contain a line break. It happens constantly — a shipping address, a comment box, a product description pasted out of a document. The rule in RFC 4180 is that such a field must be wrapped in quotes, and the line break inside it belongs to the value rather than ending the record.

The fast way to write a CSV parser is to split the text on newlines and then split each line on commas. That parser reads a three-record file with one quoted line break as four records, one of which begins mid-sentence. This one walks the file character by character and tracks whether it is inside quotes, which is slower to write and the only way to be right.

Numbers are where data goes missing

Type conversion is convenient and occasionally destructive. Two cases are worth knowing about, because both are common and neither announces itself:

Leading zeros. 00721 is a postcode, not the number 721. Convert it and the zeros are gone for good.
Long whole numbers. JavaScript holds integers exactly only up to 9,007,199,254,740,991. Past that — which covers most 17-digit order, account and barcode numbers — converting changes the final digits. 9007199254740993 becomes 9007199254740992.

Both stay as text here, and the page counts how many values were held back for that reason. You can switch conversion off entirely if you would rather every value arrive as a string.

Next steps

Going the other way is JSON to CSV, which flattens nested objects into dotted column names. If the file is too large to work with in one piece, split CSV breaks it up without cutting through a quoted field.

Frequently asked questions

Why does my first key look like "id" in other converters?

Because the file starts with a byte order mark - three invisible bytes that Excel and many Windows tools put at the front of a UTF-8 CSV. A parser that does not know about it reads those bytes as part of the first header, so you get a key you cannot type and cannot match on. This tool removes the BOM before parsing and says on the page whether it found one, so you know why the file looked strange elsewhere.

What happens to a row that has more or fewer fields than the header?

It is still converted, and it is counted. Rows with missing fields get empty strings for the columns that were not there; rows with extra fields keep them, and you can have the surplus preserved in an _extra array instead of being thrown away. Either way the page reports how many rows were short and how many were long. Most converters silently truncate or misalign these, which is how a column of values ends up shifted by one halfway down a file.

Two of my columns have the same name. What do you do?

A JSON object cannot hold the same key twice - the second value would simply overwrite the first and half your data would vanish without a message. The second occurrence is renamed, so name and name become name and name_2, and the page lists every rename it made. Blank header cells become column_1, column_2 and so on, by position.

Will my postcodes and long IDs survive?

Yes, if you leave type conversion on. Values with a leading zero such as 00721 stay text, because turning them into the number 721 destroys a postcode. Whole numbers too large for JavaScript to hold exactly - anything past 9007199254740991, which includes most 17-digit order and account numbers - also stay text, because converting them silently changes the last digits. The page counts how many values were deliberately kept as text so you can see it happened.

Does a line break inside a quoted field break the conversion?

No, and this is the single most common way CSV tools corrupt data. An address field that contains a line break is one record, not two, and a parser that splits the file on newlines before looking at quotes will cut it in half. This one reads the file character by character, so it knows whether a newline is inside quotes. The page shows the physical line count next to the record count: when they differ, you are looking at a file that a line-based tool would have mangled.

Can I choose the delimiter?

It is detected for you - comma, semicolon, tab or pipe - by counting each candidate outside quoted sections, so a semicolon-separated export from a European Excel is read correctly without being told. You can override it if the guess is wrong, and the page always says which delimiter it used.

What JSON shape do I get?

An array of objects by default, with the header row supplying the keys, which is what almost every API and import tool expects. You can also ask for an array of arrays, which keeps the raw grid without a header row, or minified output when you are pasting it somewhere that does not need to be readable.

Is my data uploaded?

No. The file is read and parsed inside your browser tab, so customer lists, exports and anything else you convert never travel to a server. There is no file size limit imposed by an upload, only by your own machine's memory.