CSV to JSON Converter

How to Convert CSV to JSON Online

CSV is the format spreadsheets, databases, and CRMs export by default because it is just text: a header row, then one line per record, with commas marking where one column ends and the next begins. JSON is what modern web apps, REST APIs, and JavaScript itself actually want to consume: an array of objects, each one keyed by field name. This converter bridges the two entirely in your browser, turning rows of a CSV or TSV export into a clean, structured JSON array in the time it takes to click a button.

The gap between these two formats shows up constantly in ordinary work. A backend developer gets a spreadsheet of test users from QA and needs it as a JSON fixture for an integration test. A frontend developer receives a product catalog exported from an inventory system and needs an array of objects to render as cards. A data analyst pulls a report out of a CRM and needs to feed it into a script that only reads JSON. None of these people want to write a parser from scratch, and none of them want to install a command-line tool for a one-off conversion that takes ten seconds here.

Step-by-Step CSV to JSON Conversion

1. Paste your CSV. Drop your rows into the "CSV Input" box, whether that is a copy-paste from Excel, Google Sheets, a database export, or a TSV file where tabs separate the columns instead of commas.
2. Set the delimiter. Leave it on "Auto-Detect" for most files, or pick Comma, Tab, Semicolon, or Pipe directly if you already know which character your export uses.
3. Choose your header and type options. Keep "First Row as Headers" checked to use your header row as JSON keys, and toggle "Parse Numbers" depending on whether numeric-looking fields, like ages or prices, should become real JSON numbers or stay as text.
4. Click "Convert to JSON." The parser builds the array in well under a second, indented the way you picked, and drops it into the "JSON Output" box below.
5. Copy or download the result. Grab it with one click of Copy, or use "Download .json" to save it as a file you can hand off, attach, or import directly into another tool.

Every step happens on your own device. There is no upload, no server queue, and no artificial row limit, since the JavaScript running in your tab does the entire job.

Why the Delimiter Matters: Commas, Semicolons, Tabs, and Pipes

"CSV" is really a family of formats rather than one strict standard, and the character separating your columns is not always a comma no matter what the file extension says. This tool ships with an Auto-Detect step for exactly that reason: it samples the first five lines of your pasted text, counts how many times each candidate delimiter (tab, comma, semicolon, and pipe) appears outside of quoted sections, and picks the character that shows up the most consistently across those lines rather than just the one that appears most often overall. A file where every line has exactly three semicolons and zero commas is a clear signal, even if a semicolon also sneaks in inside a quoted note field somewhere.

The most common surprise is the semicolon. Windows ties Excel's default list separator to your regional settings, and across most of continental Europe, the comma is already the decimal separator, so a price is written as 12,50 rather than 12.50. If Excel used a comma as the field separator too, a single price column would silently split into two columns every time it exported. To avoid that collision, Excel on German, French, Spanish, Italian, and many other European locales exports CSV files with semicolons as the delimiter instead, even though the file still ends in .csv. A row that looks like Name;Stadt;Gehalt with a value of 4500,75 is a completely standard export from a German or French spreadsheet, not a broken file.

If Auto-Detect ever guesses wrong, most often on a very short file with only one or two rows to sample, simply pick the correct delimiter from the dropdown yourself. The rest of the parsing logic, quoted fields, escaped quotes, and type inference, works exactly the same regardless of which delimiter is active.

Quoted Fields, Embedded Commas, and Line Breaks

A naive CSV parser just splits every line on the delimiter character, and that breaks the instant a field contains the delimiter itself. Real-world CSV data is full of exactly that: a "Last name, First name" column, an address with a comma before the state, a product description with a comma-separated list of features. The fix, standardized decades ago in what is now commonly called RFC 4180, is to wrap any field containing the delimiter in double quotes, and this converter implements that rule as a proper character-by-character state machine rather than a simple split.

Concretely, a row like "Doe, John",42,"New York, NY" converts correctly to a name field of "Doe, John" and a city field of "New York, NY", each staying as one value instead of splitting into extra columns. The parser tracks an inQuotes flag as it reads character by character, and only treats a comma as a field separator when that flag is off.

Escaped quotes and multi-line fields

Two related edge cases show up constantly in real exports. First, a literal double quote inside a quoted field is written as two double quotes in a row, so "She said ""hello"" to me" decodes to a single field reading She said "hello" to me, with the doubled quotes collapsed back to one. Second, a quoted field is allowed to contain an actual line break, which happens whenever a spreadsheet column holds a multi-line address, a note, or a comment. The parser does not stop reading a field at the first newline character; it keeps consuming text, newlines included, until it hits the closing quote, so a customer address exported across two physical lines still lands in JSON as a single string value with an embedded \n rather than being cut in half or spilling into the next row.

Getting this wrong is exactly what breaks spreadsheet-to-JSON conversions done with a quick regular expression or a one-line split(','). This parser exists specifically so those cases do not need to be handled by hand.

Header Rows and Duplicate Column Names

With "First Row as Headers" checked, the first line of your pasted data supplies the key name for every field in every object that follows, so a header of name,email,age means every output object has exactly those three keys, in that order. Uncheck the option for CSV data that has no header row at all, perhaps a raw database export or a log file, and the tool falls back to generic keys instead, col1, col2, col3, and so on, numbered by column position so nothing is silently dropped.

Duplicate header names deserve special attention because the failure mode is silent rather than an error message. A JSON object can only hold one property per key, so a header row like name,phone,phone, perhaps a spreadsheet with separate "work phone" and "mobile phone" columns both simply labeled "phone", produces an object where the second phone value overwrites the first during conversion. The output JSON is perfectly valid, it just quietly contains one phone number instead of two, with no warning that data went missing. The fix is entirely on the input side: rename duplicate columns before pasting, for example to phone_work and phone_mobile, so every key in the header row is unique before conversion even starts.

Type Inference: Numbers, Booleans, and the "007" Problem

CSV has no concept of data types. Every single cell, whether it holds a name, an age, a price, or a checkbox value, is stored as plain text, and it's the "Parse Numbers" checkbox that decides how much of that text gets promoted into a real JSON type rather than staying a string. With the option checked, any field that passes a numeric check is converted with JavaScript's Number(), so "age": "30" in the CSV becomes "age": 30 in the JSON, ready for math or comparison operators without an extra parsing step in your own code.

That convenience has a real cost for values that only look numeric. A product code of "007", an account number of "0042", or a ZIP code like "02139" all pass the numeric check and get converted to 7, 42, and 2139 respectively, silently losing the leading zeros that made them meaningful in the first place. A ZIP code is an identifier, not a quantity, and once it becomes the number 2139 there is no way to tell it apart from the ZIP code 21390 with a trailing digit typo. If your data has IDs, codes, or ZIP codes mixed in with genuine numeric fields, uncheck "Parse Numbers" before converting and keep everything as strings, or convert twice and manually patch just the identifier fields in the output.

Two of those rows are easy to miss: boolean conversion and empty-cell handling both happen unconditionally, regardless of the "Parse Numbers" checkbox. A cell containing the text true or false, case-insensitively, always becomes a real JSON boolean, and a genuinely empty cell always becomes null rather than an empty string "". That matters if code reading the output checks a field with === null specifically, or expects every value of a given key to share the same JavaScript type; a column that is sometimes empty will produce a mix of strings and null values across the array rather than a column of empty strings throughout.

UTF-8 vs. Windows-1252: Fixing Garbled Characters from Excel

Text encoding bugs are some of the most confusing to diagnose because the file looks completely fine in the program that made it and only breaks somewhere downstream. The classic case: a name field containing "café" or "François" gets exported from Excel, pasted into this converter or any other UTF-8-aware tool, and comes out reading café or François instead. That double-encoded garbling has a name, mojibake, and a specific cause: the file was saved using an 8-bit Windows code page, most often Windows-1252, where "é" is a single byte, but it is then read by something expecting UTF-8, where the same character takes two bytes, and each of those two bytes gets misinterpreted as its own separate character.

The fix lives in Excel's Save As dialog, not in this tool, since by the time garbled text has been pasted in, the original bytes are already gone. On Windows, choosing plain "CSV (Comma delimited)" from the file type list still defaults to the system's regional code page on many installs, while "CSV UTF-8 (Comma delimited)" explicitly writes the file using UTF-8 encoding, matching what browsers and this converter expect. If you regularly receive CSV files with garbled accented characters from a colleague, asking them to re-export using the UTF-8 option, or opening the file in a plain text editor and re-saving it with UTF-8 encoding selected explicitly, fixes the problem at the source rather than needing to be patched after the fact.

Byte order marks and trailing blank rows

Two smaller encoding artifacts are worth knowing about. Excel often prepends a byte order mark, an invisible UTF-8 signature sometimes visible as  if misread, to the very start of a UTF-8 CSV file, which is meant to help other programs detect the encoding automatically but occasionally shows up as a stray character glued to the first header name if a tool doesn't strip it. Separately, spreadsheet exports commonly end with a trailing blank line after the last real row of data. This converter filters out any row where every cell is empty before building the JSON array, so a trailing newline at the end of your file does not produce a spurious empty object at the end of your output.

Why This Converter Runs Entirely in Your Browser

Plenty of "convert CSV to JSON online" tools quietly upload whatever you paste to a server, process it there, and send back a result. That round trip is invisible in normal use, but it means your data sat, even briefly, on a machine you don't control. For a public sample dataset that's a non-issue. For a payroll export, a customer list, a vendor pricing sheet, or anything covered by a confidentiality agreement, it's a real risk that most people never think to check for.

This converter never makes that trip. The parsing logic is plain JavaScript shipped with the page, and it runs entirely inside your own browser tab the moment you click Convert. Open your browser's network tab while using it and you will not see a single request carrying your CSV data anywhere. That has a practical side effect beyond privacy too: there is no server-side rate limit, no file size cap imposed by an API, and no queue to wait behind, since your own device is doing all the work rather than a shared backend.

What that means for confidential exports

If you are converting employee records, financial data, unreleased product information, or anything else that shouldn't leave your organization, a purely client-side tool removes that risk from the equation entirely instead of asking you to trust a privacy policy you haven't read. It's the same reasoning that leads developers to run a code formatter locally rather than paste proprietary source into a random web form: the safest tool is the one that never had the chance to leak anything in the first place.

Common Ways People Use This CSV to JSON Converter

The same conversion step shows up across very different jobs. A few patterns come up constantly.

Frontend prototyping without a backend

Frontend developers building a component, a table, or a dashboard mockup often need realistic sample data before an actual API exists. Exporting a spreadsheet of sample rows and converting it here produces a ready-to-use JSON array that can be dropped straight into a mock data file or a local fixture.

Feeding a document database or NoSQL store

Databases like MongoDB store documents as JSON-like objects, not tables, so a dataset that started life as a spreadsheet export often needs to become a JSON array before it can be imported with a tool like mongoimport. Converting the export here is usually the fastest way to get from a spreadsheet to an importable file.

API testing and mock payloads

QA engineers and backend developers building test cases in tools like Postman or Insomnia frequently start with a spreadsheet of example inputs, one row per test case, and need that same data as a JSON array of request bodies. Converting once here keeps the spreadsheet as the source of truth while producing the exact JSON shape a test runner expects.

Data migration and one-off scripts

Migrating data between systems, an old CRM export into a new platform's import format, or a legacy database dump into a modern application, frequently involves a script that reads JSON. Converting the raw export here first removes the need to write a CSV-parsing step inside that script at all.

Configuration and content from spreadsheets

Non-technical teammates are often far more comfortable maintaining a list in Google Sheets than editing a JSON file directly, whether that's a list of FAQ entries, product categories, or feature flags. Converting their spreadsheet here on each update keeps the JSON file in sync with whatever they most recently edited, without them needing to touch a text editor.

Tips for Clean Conversions and Common Pitfalls

• Check the detected delimiter on short files. Auto-Detect samples the first five lines, so a file with only one or two rows gives it very little to work with. If the output looks wrong on a tiny sample, set the delimiter manually instead of trusting Auto-Detect.
• Decide on "Parse Numbers" before converting, not after. Once IDs, codes, or ZIP codes have lost their leading zeros to numeric conversion, that information is gone from the output. Scan your columns for identifier-like fields first, and leave the option unchecked if any of them look at risk.
• Watch for duplicate header names. Two columns sharing one header silently collapse into a single key in every output object. Rename duplicates before pasting, since the tool has no way to guess which duplicate you meant to keep.
• Remember that fields are trimmed. Leading and trailing whitespace around each field is stripped during parsing, so a value like " New York " comes out as "New York". This is usually what you want, but it means whitespace-sensitive data, like a code that intentionally starts with a space, will not survive the round trip.
• Re-export from Excel as UTF-8 if characters look garbled. Mojibake almost always traces back to an encoding mismatch at export time, not a bug in the paste or the parser, and the cleanest fix is a different Save As option in the source spreadsheet rather than manual cleanup afterward.
• Use the Indent option to match your next step. Pick 2 or 4 spaces for output you plan to read or commit to version control, or Minified when the JSON is headed straight into an API request or a script where file size matters more than readability.

Most conversion surprises trace back to one of these five things: the wrong delimiter, an unwanted number conversion, a duplicate header, an encoding mismatch, or trimmed whitespace. None of them are bugs in the parser, they're properties of the source data that are worth a quick glance before you click Convert.

Frequently Asked Questions

Related developer tools

🔒 100% Client-Side Privacy

All CSV parsing and JSON generation happens <strong>entirely in your browser</strong>. No data is ever uploaded to any server. Your data stays on your device at all times.