CSV to JSON Converter

About CSV to JSON Converter

CSV to JSON Converter is a free online tool that converts CSV (Comma-Separated Values) files into JSON (JavaScript Object Notation) format. Upload a CSV file or paste CSV data, choose your output format, and download the converted JSON file—all processed locally in your browser for complete privacy.

Why are all my CSV values appearing as strings in the JSON output?

Because that is exactly what they are in the source file — CSV has no type system, every cell is text. The converter defaults to producing strings to round-trip the file losslessly, but it also offers a "type inference" option that scans each column and casts cells to numbers, booleans, or null when the entire column matches a pattern. Type inference is convenient but risky: a ZIP-code column where 90% of rows are numeric will look like numbers but lose leading zeros, and a column where the string "NULL" or "N/A" means missing will be converted unpredictably. For production pipelines, prefer explicit per-column types: list which columns should be number, boolean, date, or string and let the converter apply only those rules. RFC 4180 only describes the bytes on disk, never their semantic meaning, so type decisions always live above the format.

How does the converter handle the first row — is it always treated as headers?

By default the first row is treated as the header and each cell becomes a JSON key. If your file has no header row, toggle "First row is data" and the converter will use generic keys like column_1, column_2 — or you can paste a custom header list. RFC 4180 makes the header row optional but recommends it, and most real-world CSVs include one. Watch out for headers that contain spaces, dots, or special characters: keys like "Customer ID" or "Order.Date" produce valid JSON but are awkward to access programmatically. The converter offers an optional "normalize headers" step that lowercases keys, replaces spaces with underscores, and strips non-alphanumeric characters, yielding clean snake_case identifiers like customer_id and order_date that are friendly to every downstream language.

Can I produce nested JSON from a flat CSV using dot-notation headers?

Yes. If your CSV header row contains dotted paths such as user.name, user.address.city, and user.address.zip, enable the "Expand nested keys" option and the converter will build a nested object per row: {"user":{"name":"Alice","address":{"city":"Hanoi","zip":"10000"}}}. Numeric segments are treated as array indices, so items.0.sku and items.1.sku become {"items":[{"sku":"A"},{"sku":"B"}]}. This is the inverse of the dot-notation flattening used by the JSON-to-CSV tool, so files round-trip exactly when you use both. For complex shapes that don't fit a simple path scheme — heterogeneous unions, recursive structures — write a custom mapping script in JavaScript or Python instead; the converter handles the common 80% of cases, not every imaginable schema.

What JSON output shape do I get — an array of objects, an object keyed by ID, or something else?

The default is an array of objects, one per data row, which is the most universally consumed shape and the format MongoDB, Pandas, BigQuery, and most REST APIs expect. The converter also offers two alternatives. "Object keyed by column" uses the value of a chosen column as the key, producing {"u_1":{...},"u_2":{...}} — useful when you need lookup-by-ID semantics, but it requires unique values in the key column. "NDJSON" emits one JSON object per line with no enclosing array, which is the right format for streaming pipelines (BigQuery load jobs, Spark, ClickHouse) and avoids the memory cost of buffering the full array on either side. Pick the array form for human reading and exchange; pick NDJSON for ETL at scale.

My CSV uses semicolons as delimiters and commas as decimal marks — will the converter handle that?

Yes — and you should not let it auto-detect in this case. CSVs exported by spreadsheets in regions that use the comma as the decimal mark (most of Europe, Latin America, Vietnam) typically use the semicolon as the field separator to avoid ambiguity. The converter's auto-detect tries to pick the delimiter that gives the most consistent column count, which usually catches semicolons correctly, but you should always verify by glancing at the preview. If your numeric cells use a comma as the decimal separator (1,5 for one and a half), enable type inference and select the "European number format" option, otherwise 1,5 will be parsed as the string "1,5" rather than the number 1.5. Different locales also disagree on the thousand separator — make those rules explicit.

How does the converter handle empty cells, missing values, and the literal text "null"?

By default an empty cell becomes the JSON value null, the literal text "null" stays a string, and a cell containing only whitespace is also treated as empty. You can change all three behaviours. "Empty cells as empty string" produces "" instead of null — better when consumers strictly type-check fields and reject null. "Treat NA, N/A, NULL as null" parses those common sentinel strings as JSON null, useful when your source uses one of those conventions. For numeric columns, an empty cell with type inference enabled becomes null rather than 0, which prevents the common mistake of summing missing values as zero. RFC 4180 does not define semantics for empty fields, so you must pick a convention and stick with it across your pipeline.

What is the largest CSV I can convert in the browser without crashing?

Practical limits are around 50 MB or 500 000 rows on a modern desktop browser; the parser uses a streaming approach internally, but the resulting JSON has to be materialised in memory before it can be displayed or downloaded. For files in the gigabyte range, switch to a command-line streaming converter: Miller's mlr --icsv --ojsonl cat input.csv > output.ndjson emits NDJSON one row at a time and uses constant memory regardless of file size, DuckDB's COPY (SELECT * FROM read_csv_auto('input.csv')) TO 'out.ndjson' (FORMAT JSON, ARRAY false) is equally efficient and adds type inference, and the Python csv + json modules combined in a generator pipeline will process arbitrary sizes. For very wide files (thousands of columns), prefer Parquet over JSON — column-oriented storage compresses far better and queries selectively without reading the full document.

How do I escape special characters or convert dates and ISO timestamps properly?

Quoting and escaping at the CSV level follow RFC 4180: fields containing the delimiter, double quotes, or newlines must be wrapped in double quotes with internal quotes doubled, and the converter handles that automatically on input. On the JSON output side, the standard JSON escapes apply: \" for double quote, \\ for backslash, \n \r \t for control characters, and \uXXXX for any Unicode code point above the printable ASCII range. Dates are not a native JSON type, so the converter emits them as ISO 8601 strings (2026-05-17T00:00:00Z) when date type inference is enabled — this is the only universally interoperable date format, accepted by JavaScript's Date constructor, Python's fromisoformat, Java's Instant.parse, and all major SQL engines. Avoid locale-specific formats like 17/05/2026 in your output.