CSV to JSON bulk conversion is the controlled conversion of one comma-delimited CSV table containing up to 5,000,000 UTF-16 code units and 10,000 data rows into a pretty-printed JSON array while preserving every cell as a JSON string. The CSV To JSON tool performs this work in the current browser tab: paste one comma-delimited table, convert it, inspect the reported counts, review the JSON, and then copy or download the result. Its first CSV record becomes the exact JSON header, and every data record becomes one object. Header order determines property order, while every cell becomes a string. The converter therefore does not guess that 001 is a number, that true is a Boolean, or that null represents a JSON null value. Quoted commas, doubled quotes, and line endings embedded inside quoted fields are preserved according to the supported CSV syntax. After a successful conversion, the data-row, column, cell, and UTF-8 output-size summary provides a quick consistency check. Here, bulk refers to the number of records that can be handled in one bounded table, not a queue of multiple CSV files. To convert separate files, run the conversion separately for each table. The complete parsing, validation, serialization, measurement, and export process happens locally; no CSV or JSON is uploaded.
Bulk conversion means one bounded table
The important distinction is between bulk data and batch files. This tool is designed for scale within one pasted text table. It can process as many as 10,000 data records, 200 columns, and 200,000 data cells, but those maximums work together rather than as independent suggestions.
A wide table with relatively few rows can reach the 200,000-cell limit before reaching 10,000 rows. Conversely, a narrow table with many short records is limited by the row count and output-size budget. A table with substantial JSON escaping can consume the UTF-8 output limit faster than its raw input size suggests.
These are enforced limits, not silent caps. Exact boundaries are accepted, while one code unit, row, column, cell, or UTF-8 byte beyond a boundary causes conversion to fail explicitly. A successful conversion produces the complete JSON array. A failure does not return a partial array, so downstream code does not need to guess whether some records were omitted.
Prepare a table for strict parsing
Prepare the input before conversion so the first record can serve as the exact header. Every header must remain nonempty after an optional leading UTF-8 BOM is handled. Header names must be unique, and comparison is exact and case-sensitive. Whitespace is part of the header, so id, Id, and a name containing a leading space are different keys. The converter does not trim them.
- Use commas as the only field delimiter. Tabs, semicolons, and pipes remain ordinary field characters.
- Put the same number of fields in every data record. Short rows, long rows, and a final record ending that appears to create another record are handled according to the parser rules, but every actual data record must match the header width.
- Use unquoted fields or enclose fields in double quotes. A quoted field can contain commas, CRLF, LF, CR, and doubled double quotes. Two consecutive quotes inside a quoted field decode to one literal quote.
- Keep quote syntax exact. An unquoted quote, an unclosed quote, or trailing content after a closing quote is rejected rather than repaired or discarded.
Outside quoted fields, CRLF is the canonical record ending. Standalone LF and standalone CR are accepted as interoperability extensions. A final record ending is optional and does not create an extra empty record, while a second consecutive record ending represents a blank record. Line endings inside quotes remain field data with their original CRLF, LF, or CR spelling.
The parser does not auto-detect another delimiter, skip comments, trim fields, discard blank records, merge uneven rows, or infer a schema. One U+FEFF at the very beginning of the input is consumed as a common UTF-8 BOM, including when the first field is quoted, and the raw input budget is checked before that removal. U+FEFF in any other position remains data. If a file contains only the BOM, it becomes empty after normalization and reports a required-input error.
Convert and verify one CSV table
- Paste the CSV. Paste one comma-delimited text table into the tool. Confirm that its first record contains nonempty, unique, case-sensitive header names and that every data record has exactly the same number of fields.
- Convert and check the summary. Run the conversion, then verify the reported data-row, column, data-cell, and UTF-8 output sizes. These figures help confirm that the table is rectangular and within every enforced limit.
- Review the JSON strings. Check representative values and scan the full output for type changes. The value 001 should remain “001,” true should remain “true,” null should remain “null,” and an empty cell should remain an empty JSON string.
- Copy or download the file. Once the object mapping, values, and size summary are correct, copy the complete JSON or download it as converted.json. Editing the source input clears the previous output, counts, errors, and copy state so stale JSON is not reused.
Check object mapping and string values
The conversion maps table structure directly to JSON structure. Reviewing that mapping before export is important because the tool preserves cell text rather than interpreting it as a database or spreadsheet would.
| CSV input | JSON result |
|---|---|
| Complete table | One pretty-printed JSON array |
| First record | Exact object keys |
| Header order | Property order |
| Each data record | One object |
| Every cell | One JSON string |
| Empty cell | Empty string |
| Quoted comma | Comma inside the same string |
| Doubled quote | One literal quote |
| Embedded line ending | Line-ending text inside the string |
Internally, each record is built as a null-prototype object before serialization. As a result, names such as __proto__, constructor, prototype, and toString are ordinary own string keys rather than inherited object properties. JSON.stringify then escapes property names, quotes, backslashes, control characters, and embedded line endings while using two-space indentation. The result is valid JSON data, not executable code. A receiving application must still parse and validate the JSON according to its own requirements.
Stay within enforced conversion limits
Check every relevant limit before attempting a large conversion. A table must fit within the following product-defined boundaries:
| Measured item | Maximum | Measurement detail |
|---|---|---|
| Raw input | 5,000,000 UTF-16 code units | Checked before a leading U+FEFF is consumed |
| Data rows | 10,000 | The header is not counted as a data row |
| Columns | 200 | Every data record must match the header width |
| Data cells | 200,000 | A wide table can reach this before the row limit |
| Generated JSON | 10,000,000 UTF-8 bytes | Measured with TextEncoder, not JavaScript string length |
Multibyte Unicode affects the generated JSON size according to its UTF-8 bytes, not its JavaScript string length. This is why a table can fit within the raw code-unit budget yet fail during output measurement. Exact row, column, cell, and byte boundaries are accepted. One unit beyond a boundary fails explicitly, and the same complete-conversion rule applies. If a row width is invalid or an output-size boundary is exceeded, no partial JSON or stale download remains available.
Retain source context when reviewing output
String-preserving conversion should not be confused with returning the original file byte for byte. The first leading BOM is consumed before header parsing, while a BOM elsewhere remains data. Outside quotes, record endings are structural delimiters rather than serialized cell content. Inside quotes, the supported ending is preserved as part of the string with its original spelling. The tool also does not normalize Unicode.
The converter does not execute spreadsheet formulas, fetch linked values, validate business meaning, infer a schema, flatten structures, deduplicate records, or rename keys. Review header names, counts, quoting, and representative string values before importing the JSON. Retain the source CSV when its original quoting or line-ending presentation may matter during review or debugging.
Keep bulk conversion local in the browser
All parsing, object construction, UTF-8 measurement, copying, and Blob creation happen locally in the current browser tab. The tool does not fetch linked values, and neither the pasted CSV nor the generated JSON is uploaded as part of conversion.
State cleanup is built into the workflow. Editing the CSV revokes the old JSON ObjectURL and clears the previous output, errors, summary, copy state, and timer. Conversion failure also revokes download state and leaves no stale file. These controls prevent an earlier successful result from being mistaken for a newer edited input.
For a dependable bulk conversion, confirm the first-record header rules, check that every record has the same width, review the reported limits, verify that all cells remain strings, and then copy or download converted.json. This keeps the result predictable and leaves the final business validation to the receiving application.