Convert a CSV to a JSON Array or NDJSON

In short: RowSlice's CSV to JSON converter turns each data row into one flat JSON object, in your browser, without the file being uploaded. You choose the shape — one array, or one object per line as NDJSON — and whether values are written as strings or as real JSON types. The default is strings, so 00742 stays 00742 and a 19-digit order number keeps all 19 digits. Empty cells can be written as "", as null, or left out of the object entirely. The CSV is read about 4 MB at a time and one row is held at a time, so a multi-gigabyte export converts the same way a small one does.

How to Convert a CSV to JSON

1. Choose or drag in the CSV. It is read from your own disk rather than uploaded, so even a large file is ready in a second, and the first rows appear as a preview with the delimiter and encoding that were detected.
2. Pick the shape: array for one JSON document, NDJSON for one object per line. The next section shows both from the same input.
3. Leave Values on text unless the consumer needs real numbers. Text is what keeps identifiers intact.
4. Decide what an empty cell should mean — "", null or a key that is not there — and press Convert to JSON.
5. Download yourfile.json or yourfile.ndjson. The result says how many keys were written and how big the file is, so you can check the count against the columns your header had.

Array or NDJSON?

Both shapes come from the same reading of the file. This CSV:

order_id,sku,qty,ship_to_zip
1001,SEP-1,2,00742
1002,A-77,1,10013

becomes this as an array, with Pretty print on:

[
  {
    "order_id": "1001",
    "sku": "SEP-1",
    "qty": "2",
    "ship_to_zip": "00742"
  },
  {
    "order_id": "1002",
    "sku": "A-77",
    "qty": "1",
    "ship_to_zip": "10013"
  }
]

and this as NDJSON:

{"order_id":"1001","sku":"SEP-1","qty":"2","ship_to_zip":"00742"}
{"order_id":"1002","sku":"A-77","qty":"1","ship_to_zip":"10013"}

The array is a single document: a reader has to reach the closing bracket before it has anything. NDJSON is a file of independent objects, one per line, so a reader can act on the first record while the rest is still arriving, and a broken line is one broken record rather than a file that will not parse. NDJSON is never indented — indenting it would put one object across several lines and no NDJSON reader would find them.

Turn Pretty print off and the array is the same document without the indentation. It still puts one object on each line, which is deliberate: a converted export ends up in an editor or a diff sooner or later, and a single ten-million-object line is neither readable nor openable. Pretty print does not apply to NDJSON, which is one object per line by definition.

Why Every Value Is a String by Default

A CSV records no types. 00742 is five characters, and the only thing that can be said about it with certainty is that it is those five characters. Writing it as a JSON number turns it into 742, and no later step can tell that a zip code was lost rather than a quantity written oddly. So text is the default, and in text mode every value in the file is written as a JSON string.

Auto is for the JSON you are going to do arithmetic on. It writes a value as a real JSON number only when writing it as a number and reading it back would give exactly the same text — the same test the CSV to Excel converter uses, and for the same reason. The same input as above, in auto mode:

{"order_id":1001,"sku":"SEP-1","qty":2,"ship_to_zip":"00742"}
{"order_id":1002,"sku":"A-77","qty":1,"ship_to_zip":"10013"}

order_id and qty are numbers now. ship_to_zip is still a string, in the same file, because the test runs on each value rather than on the column it sits in. Here is what auto mode refuses, and why:

Those refusals are the feature, not a gap in it. Turning a long identifier into a rounded double is the loss that Excel is best known for, and JSON's numbers are the same double: RFC 8259, the JSON specification, notes that readers generally use IEEE 754 double precision, which holds 15 significant decimal digits exactly and rounds whatever comes after them. So the same care applies.

Empty Cells: "", null, or Left Out

An empty cell in a CSV means nothing in particular — it is a delimiter followed by another delimiter. What it should become in JSON depends entirely on what reads the JSON, so it is a setting rather than a guess. Given this row:

id,email,phone
7,ann@shop.com,

the three choices write, in order, an empty string, a null, and no key at all:

{"id":"7","email":"ann@shop.com","phone":""}
{"id":"7","email":"ann@shop.com","phone":null}
{"id":"7","email":"ann@shop.com"}

Empty string is the default and the most literal: it says the cell was there and held no characters.null is what most databases and schema validators mean by a missing value, and it is the one to pick when the JSON is going into a typed field. Omit leaves the key out, which is right for an API that treats a present key as an instruction to set that field — sending "" there would blank a value you meant to leave alone. The cost of omit is that objects stop having identical key sets, so code that loops over the rows has to cope with a missing key, and a row whose every value is empty comes out as {}. The other two modes always write every key.

How Large a CSV Can It Convert?

The converter never holds the document. The CSV is read about 4 MB at a time, one row is turned into one object and written out, and what stays in memory is a fixed structure per column — the key names — never one per row. A 40 GB file costs what a 40 KB one costs. The output goes to your browser's private on-disk storage (OPFS) as it is produced, not into a string that has to fit in the tab.

So the limit is disk, not memory, and the number to plan for is not the size of your CSV. JSON repeats every key on every row: a CSV writes order_id once and JSON writes it ten million times. Expect the output to be a multiple of the input, more so when the column names are long and the values are short, and keep that multiple inside the storage your browser gives one site — about 10 GB in Firefox. The written size is on the result before you download anything.

If you do not know how big the job is yet, the analyzer counts the rows and columns and reports the encoding and delimiter without writing a file, which is the cheapest way to size the conversion first. When the JSON is going into an import or an endpoint that has not taken it before, convert a sample of a few thousand rows and send that through first: finding out that the key names are wrong costs a second rather than a full conversion. And when only part of the export is wanted at the other end, cutting the CSV down to those rows first leaves fewer objects to write.

What It Does Not Do

It does not nest. A CSV is flat, so the JSON is flat: one object per row, one key per column, values that are strings, numbers or booleans and never objects or arrays. A column named address.city becomes a key with a dot in it, not a branch. Building a shape out of column names would mean inventing structure the file never recorded.

It does not infer a schema. There is no per-column type detection, no date parsing and nonull detection: the word null in a cell is the string "null", and 03/04/2026 is a string in every mode, because a CSV does not say whether that is April or March. Auto mode is the whole of the type conversion, and the table above is the whole of auto mode.

It reads CSV, not JSON. One file per run, in, and one file out. To go the other way — a JSON array or an NDJSON export into a spreadsheet-ready file — use the JSON to CSV converter, which flattens nested keys into dotted column names. To get a workbook instead of JSON, convert the CSV to .xlsx.

Last updated September 22, 2026.