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 (the "First row is header" checkbox) and each cell becomes a JSON key. If your file has no header row, uncheck it and the converter will use generic keys like column_1, column_2 for Array of Objects and NDJSON output, or emit plain arrays for Array of Arrays. 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. Dotted headers are special — see the nested-keys question, where enabling "Expand Nested" turns Order.Date into a nested object. For other cleanup such as lowercasing or converting to snake_case, normalize the header row in your source file first, then convert.

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. Choose "Array of Arrays" instead when you want a plain matrix that mirrors the CSV structure with no keys. The third option, "NDJSON" (JSON Lines), emits one JSON object per line with no enclosing array, which is the right format for streaming pipelines (BigQuery load jobs, Spark, ClickHouse, Elasticsearch _bulk) and avoids the memory cost of buffering the full array on either side — the download switches to a .ndjson file automatically. Pick the array form for human reading and exchange; pick NDJSON for ETL at scale. If you need a different shape such as an object keyed by an ID column, post-process the array-of-objects output with a short script.

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

Yes — set the delimiter to Semicolon (or leave it on Auto-detect, which usually catches semicolons correctly), and always verify by glancing at the preview. 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. One caveat: this tool does not reinterpret comma-decimal numbers, so a cell containing 1,5 (one and a half) is kept as the string "1,5" rather than being cast to 1.5 — that is the safe, lossless behavior. If you need true numeric 1.5 values, search-and-replace the decimal commas with dots in your source file before converting, or do the locale-aware numeric parsing in your downstream pipeline where the thousand-separator rules are explicit.

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

With Type Inference enabled, an empty cell becomes the JSON value null rather than 0 or an empty string, which prevents the common mistake of summing missing values as zero, while the literal text "null" stays the string "null" and sentinel strings like NA or N/A are also preserved verbatim — the tool never silently reinterprets them. With Type Inference disabled, every cell is kept as a string, so an empty cell becomes "". If your source uses NA, N/A, or NULL to mean missing and you want real JSON null, normalize those values in the source file first, or map them in your downstream pipeline. 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.