CSV vs JSON: which format to use for your data

CSV

• Every record has the same flat fields, with no lists or sub-objects.
• The file goes to Excel, Google Sheets or a database import.
• You want a compact text file, since the column names appear only once.

JSON

• Records hold nested objects, lists, or fields that only some records have.
• The data comes from or goes to a web API.
• Readers must tell 1, "1", true and null apart without guessing.

For millions of records, two other formats often fit better: JSONL keeps JSON's structure with one record per line, and Parquet stores typed columns in a compressed binary file. rows.page opens and exports both.

Here are three records as CSV, with the column names once on the first line:

id,name,active,city
1,Alice,true,Amsterdam
2,Bob,false,Berlin
3,Cara,true,

And the same records as a JSON array of objects, with the city inside a nested address object:

[
  {"id": 1, "name": "Alice", "active": true, "address": {"city": "Amsterdam"}},
  {"id": 2, "name": "Bob", "active": false, "address": {"city": "Berlin"}},
  {"id": 3, "name": "Cara", "active": true, "address": {"city": null}}
]

In the CSV, every value is text and Cara's missing city is an empty field at the end of line 4. In the JSON, numbers and booleans are unquoted, the missing city is an explicit null, and every key repeats in every record.

Because CSV has no types, every reader guesses them. DuckDB, for example, samples the file and reads id as a number and active as a boolean, while Excel keeps only 15 significant digits, so long numeric IDs can lose digits. JSON writes the type into the file: 1 is a number and "1" is a string.

RFC 4180 is informational: it documents the common practice of a comma between fields and double quotes around values that contain commas, quotes or line breaks, and many tools still write semicolons, tabs or pipes instead. JSON has one grammar, defined by RFC 8259 and ECMA-404.

rows.page

1. Drop a .csv or .txt file on rows.page, or click Paste data and paste cells copied from Excel or Google Sheets. The delimiter (comma, semicolon, tab or pipe) and the header row are detected for you.
2. Optionally filter rows, for example with price:>20, or run SQL against the table data.
3. Open Export and pick JSON for one array of objects keyed by the header row, or JSONL for one object per line.

DuckDB-WASM reads the file in your browser, so nothing is uploaded unless you press Share.

DuckDB

COPY (SELECT * FROM 'data.csv') TO 'data.json' (FORMAT JSON, ARRAY true);

Without ARRAY true, DuckDB writes one object per line, which is JSONL.

rows.page

1. Drop a .json, .jsonl, .ndjson or .ldjson file on rows.page, or paste it.
2. A single top-level object such as {"data": [...]} is unwrapped to its biggest list, up to 4 levels deep, with a note that the other top-level fields were skipped.
3. Nested objects become dot-path columns such as address.city, up to 8 levels deep and 200 child fields per object, and arrays stay list columns that show the first 6 items and "+N".
4. Open Export and pick CSV.

The CSV is comma-delimited UTF-8 without a BOM, and cells that start with =, +, -, @, a tab or a carriage return get a leading apostrophe so spreadsheets don't run them as formulas. To query a nested field first, put the dot-path column in double quotes, as in SELECT "address.city" FROM data.

DuckDB

COPY (SELECT id, name, active, address.city AS city FROM 'data.json') TO 'data.csv' (HEADER);

Name nested fields explicitly, as with address.city here, so each one gets its own CSV column.