Fast, practical, browser-based developer tools
Upload a CSV file or paste CSV text, then convert it into JSON instantly in your browser. This tool is useful for API preparation, importing spreadsheet data into applications, creating test fixtures, transforming exports, and quickly turning rows into structured JSON objects.
CSV is widely used for spreadsheets, exports, and tabular data, while JSON is one of the most common formats for APIs, applications, and structured data workflows. This converter helps you bridge those formats quickly by transforming CSV rows into JSON objects without needing a script or command-line tool.
This CSV to JSON converter is designed to work in your browser. That means the CSV text you paste and the CSV files you load are processed locally on your device during the conversion workflow instead of being uploaded as part of the tool’s normal operation.
For more details about site usage and analytics, read our Privacy Policy.
Upload a CSV file or paste CSV text into the input area, then click Convert to JSON. The first row is treated as the header row, and each following line is converted into one JSON object using those header names as keys.
name,age,city John,30,New York Sara,25,London
[
{
"name": "John",
"age": "30",
"city": "New York"
},
{
"name": "Sara",
"age": "25",
"city": "London"
}
]
CSV stores everything as text; JSON has real types. The whole difficulty of this direction is deciding what each string means. This converter keeps values as strings, which is the safe default, because automatic type coercion quietly destroys data that only looks numeric.
Consider a column of zip codes: coerce 01234 to a number and it becomes
1234, the leading zero gone forever. A product code like 1E5
becomes the float 100000. A phone number +441632960000,
an ISBN with an X check digit, a 20-digit account number that overflows
253 — all corrupt the moment a parser is clever about types. Booleans have the
same problem: is the string "NO" the boolean false or the country code for
Norway? If you do want typed output, apply coercion column by column where you know the
data, never blindly across the whole file.
The tempting one-liner — split on line breaks, then split each line on commas — is wrong, and it fails on exactly the data you care about. Under RFC 4180 a field may contain a comma, a quote, or a newline as long as it is wrapped in double quotes. So a single cell holding a multi-line address is one field spanning several physical lines, and a naive line-splitter shreds it into several broken rows.
Correct parsing has to track whether it is currently inside a quoted field, treating commas
and newlines as literal text until the closing quote, and un-doubling any ""
into a single quote. This is why "just parse the CSV yourself" is a common source of bugs
and why the quoting rules, not the commas, are the hard part of the format.
Despite the name, plenty of "CSV" files are not comma-separated. In locales where the comma is the decimal separator — much of Europe — Excel exports use a semicolon instead, because the list separator follows the operating system's regional settings. Tab-separated files (TSV) are common too. Feeding a semicolon-delimited file to a comma-based parser produces a single giant column, so confirm the delimiter before you trust the output.
There is also an invisible trap in the header row. A file saved as "UTF-8 with BOM" begins
with a byte-order mark (U+FEFF), which gets glued onto the first column name. The result is
a first key that looks like id but is actually id, so
record.id comes back undefined for no visible reason. Strip the
BOM before splitting the header.
Turning rows into objects assumes the header row is clean, and real exports often are not.
If two columns share a name — two notes fields, say — the second overwrites the
first in the resulting object, because a JSON object cannot hold two identical keys. Blank
header cells produce empty-string keys that are easy to miss.
Rows can also be ragged: a row with fewer values than headers leaves trailing fields empty (this tool fills them with empty strings), while a row with more values than headers has nowhere to put the extras. A stray unquoted comma inside a value is the usual cause of a row that suddenly has one column too many.
This tool keeps values as strings, which is deliberate. Automatic coercion corrupts
data that only looks numeric — a zip code 01234 loses its leading zero, a
long account number overflows JavaScript's 253 precision limit. Convert
specific columns yourself where you know the type is safe.
A CSV field can legally contain newlines when it is wrapped in double quotes, so a parser that splits on line breaks first will tear such a field apart. Make sure the value is properly quoted; a correct parser tracks quote state and keeps the newline as part of the field.
Yes, in practice. Excel uses the operating system's list separator, which is a semicolon in locales where the comma is the decimal mark. A comma-based parser will read such a file as one big column, so set or detect the correct delimiter first.
The file probably has a byte-order mark. Saved as "UTF-8 with BOM", it prepends an
invisible U+FEFF to the first header, so the key becomes id rather than
id and property access misses it. Remove the BOM before parsing.
A JSON object cannot hold two identical keys, so the later column overwrites the earlier one and you silently lose a field. Rename duplicate headers before converting if both columns matter.
A short row leaves the trailing fields as empty strings. A long row has more values than headers, and the surplus has nowhere to go — usually a sign of an unquoted comma inside a value that split one field into two.