CSV vs JSON vs Excel: Which Format When?

CSV is a flat table and nothing more: rows and columns of plain text. Its strengths are universality and size — every tool reads it, and a million rows stay small. Its limitation is that it cannot express nesting. There is no clean way to put a list of tags or an address object inside a single cell without inventing a convention. Reach for CSV when your data is genuinely tabular and you want maximum compatibility: bulk imports, database dumps, and hand-off to analysts.

It also has no types and no schema. Every value stays text until something interprets it, and nothing in the file records which column is the key or what a blank cell means. In exchange you get streaming: a reader can walk a ten-gigabyte file line by line without holding it in memory, and because the text repeats itself so much it compresses to a small fraction of its size. For moving flat data in bulk, that combination is hard to beat.

JSON represents structured, nested data and distinguishes types — strings, numbers, booleans, null, plus objects and arrays. That makes it the natural language of web APIs and configuration files, where a record often has sub-objects and lists. The trade-off is verbosity and the need for parsing. When your data has a shape — an order containing many line items, a user with a list of roles — JSON expresses it directly, where CSV would force you to flatten or split it across files.

Two details catch people out. JSON has no date type, so timestamps travel as strings, and ISO 8601 — 2026-09-20T14:05:00Z — is the convention that keeps them unambiguous and sortable. And most parsers decode numbers as IEEE 754 doubles, which hold integers exactly only up to two to the fifty-third power, so a nineteen-digit identifier read as a number comes back subtly wrong. Long ids belong in quotes. For large files, JSON Lines — one object per line, with no enclosing array — restores the line-by-line streaming that CSV gives you for free.

Excel (XLSX) is a rich binary format designed for people, not programs. It carries multiple sheets, cell formatting, formulas, charts and data types. It is perfect for reports a human will open and edit, but it is a poor exchange format for automation: it is heavier, harder to parse, and its formulas and formatting are irrelevant once data crosses into another system. A common and healthy pattern is to keep working files in Excel but export to CSV whenever data needs to move into a database, a script or an API.

When you do need to cross the CSV/JSON line, the CSV ↔ JSON tab handles both directions: it turns a table's header into object keys, optionally inferring numbers and booleans, and flattens an array of objects back into a spreadsheet.

The three formats fail at different points. An Excel worksheet holds 1,048,576 rows and 16,384 columns — the ceiling of the XLSX format since 2007 — and a larger CSV opens with a warning that the file was not loaded completely, keeping only the first million or so rows. CSV itself has no row limit; the limit is whatever reads it. Google Sheets counts cells rather than rows, so a wide table reaches its cap long before a narrow one does.

Size behaves differently too. The same data as JSON is usually several times larger, because every record repeats every key. XLSX is a zip archive of XML, so on disk it can be smaller than the raw CSV while being far slower to parse. Choose by what reads the file next: a text editor and command-line tools handle CSV at any size, while anything that has to open in Excel should stay under the row limit or be split into parts.

For analytics on large volumes there are columnar formats, Parquet above all. Data is stored column by column, typed, and compressed per column, so a query reads only the fields it asks for; pandas, DuckDB and Spark all read it directly. The price is that the file is unreadable by a person and needs a library, which makes it a poor thing to email to a colleague who works in a spreadsheet.

When the data has relationships and gets read many times, SQLite is the sensible middle ground: a single file holding real tables, types, indexes and constraints, queried with SQL and needing no server. A short way to hold all of it in your head — CSV and JSON are transport, Parquet and SQLite are storage, Excel is presentation. Most confusion about formats comes from using one of them for a job that belongs to another column of that list.