Comparison

CSV vs JSON

CSV stores a flat table of rows and columns. JSON stores nested structures with types. CSV is smaller, streams row by row and opens in any spreadsheet. JSON preserves nesting, distinguishes numbers from strings and is what APIs speak. Choose CSV for tabular data going to people or spreadsheets, and JSON for structured data going to code.

CSV to JSON Converter

Turn CSV rows into a clean JSON array of objects.

Open the tool

The question is usually settled by two things: whether the data is genuinely tabular, and who or what is going to read it. Records with the same handful of fields, destined for someone who will open them in Excel, want CSV. Nested objects destined for an application want JSON.

Trouble starts when data is forced into the wrong one. Nested data in CSV needs flattened column names and the structure is inferred rather than stated. Large flat tables in JSON repeat every key on every record, which can double the file size for no benefit.

What actually differs

  • Structure: CSV is strictly two-dimensional; JSON nests to any depth.
  • Types: CSV values are all text — the reader decides what they mean. JSON distinguishes strings, numbers, booleans and null.
  • Size: CSV writes each column name once; JSON repeats every key on every record.
  • Streaming: CSV is naturally line-by-line. JSON needs the whole document, unless you use NDJSON.
  • Tooling: every spreadsheet opens CSV. Every programming language parses JSON without a mapping step.
  • Ambiguity: CSV has no standard for the delimiter, quoting or whether a header exists. JSON has one unambiguous grammar.

The typing problem

This causes more real damage than anything else here. CSV has no types, so whatever reads the file guesses — and spreadsheets guess badly. A product code of 007 becomes the number 7. A long identifier becomes scientific notation. A date shifts format depending on locale. JSON avoids all of it by stating that "007" is a string. If you must send CSV containing codes with leading zeros, say so to the recipient, because the file itself cannot.

Choosing CSV

When the data is genuinely a table and a person may open it.

  • Exports a colleague will open in Excel or Sheets.
  • Large flat datasets where repeating keys would waste significant space.
  • Anything processed a row at a time without loading the whole file.
  • Bulk import into systems that expect a spreadsheet.

Choosing JSON

When structure or types matter, or when code is the consumer.

  • API requests and responses.
  • Records with nested objects, arrays or optional fields.
  • Configuration, where a wrong type silently changes behaviour.
  • Anything where the shape should be validated against a schema.

Converting between them

JSON to CSV loses nesting unless it is flattened into dot-separated columns such as address.city, and loses type information entirely. CSV to JSON gains structure but has to guess types, which is why type conversion should be off for anything with a meaningful leading zero. Neither direction is lossless, so convert deliberately rather than treating them as interchangeable. NDJSON is worth knowing about as a middle ground: one JSON object per line, so it streams like CSV while keeping types and nesting.

Frequently asked questions

Which is smaller?
CSV, usually by a wide margin for flat data, because JSON repeats every key on every record. Compression narrows the gap considerably since those repeated keys compress well, so the difference matters most for uncompressed storage.
Why do my leading zeros disappear in CSV?
Because CSV has no types and the spreadsheet guesses. It reads 007 as a number and drops the zeros. The file is not at fault — there is nothing in the format able to say "this is text". Import as text, or use JSON.
Can CSV represent nested data?
Only by flattening it into columns such as address.city, which works but makes the structure a convention rather than something the file states. If the nesting is deep or the arrays vary in length, the result becomes unwieldy and JSON is the better fit.
What about NDJSON?
A good middle ground: one complete JSON object per line, so it streams line by line like CSV while keeping types and nesting. It is common for logs and bulk import APIs, and it is what to reach for when a JSON array is too large to load at once.
Is converting between them lossless?
No, in either direction. JSON to CSV loses nesting and types. CSV to JSON has to infer types, and inferring wrongly is how identifiers get mangled. Convert with the options set deliberately and check the first record.

Tools used in this guide

All tools →
All guides →

Last reviewed .