JSON or CSV: how to choose for real-world data

Short answer: neither is universally better. Choose CSV for flat, tabular datasets and JSON when you need nested structure or typed values. The sections below explain the tradeoffs with examples and standards references, then give you a simple checklist to decide.

What each format is, in standards terms

CSV is a plain-text representation of rows and fields. RFC 4180 documents common CSV practice: one record per line (CRLF line breaks), an optional header row, fields separated by commas, and double quotes to enclose fields with commas, quotes or line breaks; an embedded double quote inside a quoted field is escaped by doubling it. The registered media type is text/csv. See the details in RFC 4180.

JSON is a lightweight, text-based data format that represents objects and arrays and supports primitive types string, number, boolean and null. Its grammar permits nested structures and numbers with optional fraction and exponent parts. The registered media type is application/json. See RFC 8259.

When CSV is the better choice

• Your data is inherently tabular: one record per row with a consistent set of columns.
• Consumers are spreadsheet tools or bulk loaders that expect delimited text.
• You want a stream of tabular records. Use a CSV-aware parser: a quoted field can contain a line break, so a physical line is not always a complete record. RFC 4180 also allows an optional header. See RFC 4180.

Remember CSV’s quoting rules from RFC 4180 if fields may contain commas, quotes, or line breaks: enclose such fields in double quotes and escape a double quote inside a field by writing it twice.

When JSON is the better choice

• Your data has hierarchy: nested objects or arrays that don’t flatten cleanly into columns.
• You need to preserve types across systems: strings, numbers, booleans and null as defined in RFC 8259.
• APIs or applications will consume the data as objects and arrays, not just as rows.

If you plan to validate payloads against rules (e.g., required fields, numeric constraints), JSON works naturally with a schema layer. See our primer on what JSON Schema is used for in practice. For a refresher on objects vs arrays, see the difference between {} and [] in JSON.

Interoperability note: media types

If you’re serving files over HTTP, advertise the correct media type: application/json for JSON (RFC 8259) and text/csv for CSV (RFC 4180).

Practical examples

JSON (nested record)

{"id": 123, "name": {"first": "Ava", "last": "Reyes"}, "emails": ["ava@example.com", "a.reyes@example.org"]}

CSV (flattened view of the same logical data)

id,name_first,name_last,emails
123,Ava,Reyes,"ava@example.com;a.reyes@example.org"

The CSV example flattens the emails array into a single field with a chosen internal delimiter; that convention is outside RFC 4180 and must be agreed with the consumer. JSON preserves the array directly per RFC 8259.

Common pitfalls to avoid

CSV specifics (RFC 4180)

• Line breaks: the RFC uses CRLF for record delimiters; some tools accept other newlines, so test a sample import. See RFC 4180.
• Quoting: always quote fields containing commas, quotes, or line breaks; escape embedded quotes by doubling them.
• Headers: if you emit a header row, keep column counts consistent with all data rows.

JSON specifics (RFC 8259)

• Types: only strings, numbers, booleans, null, objects and arrays are valid values; tokens like NaN or Infinity are not permitted.
• Numbers: integers and decimals are both JSON numbers; fraction and exponent parts are allowed by the grammar. See RFC 8259.
• Encoding: for networked exchange, use UTF‑8 as required by RFC 8259.

How to decide quickly

Use this simple rule of thumb, then confirm with a short test: CSV for flat tables, JSON for nested or typed structures.

Short FAQ