Data formatsDecision report7 repeated rounds

CSV vs JSON Lines parsing for simple tabular records

A same-record comparison of CSV and JSON Lines parsing, including input byte size.

Decision brief

The choice this benchmark informs

For 400 simple flat records, how do CSV and JSON Lines compare in parsing time and source size on this host?

Operational exports are chosen for interoperability, schema clarity, streaming behavior and error recovery—not only parser throughput.

CSV dialect details can become a correctness burden when values contain delimiters, quotes or newlines. JSON Lines has its own overhead but a clearer per-record boundary.

Result and trade-off

Lowest measured medianJSON Lines rows
Median time226.01 µs
Median spread152.06%

What this run shows: JSON Lines rows parsed this simple record fixture faster. Typing, escaping, schema evolution and producer compatibility remain part of the format choice. The slowest-to-fastest median spread was 152.06% on the measured host.

Measured results. Lower median time is faster.
VariantMedianMiddle 50%Operations/sAdditional measure
JSON Lines rowsFastest226.01 µs225.22 µs–228.16 µs4,42521,802 input bytes
CSV rows569.66 µs568.26 µs–592.05 µs1,7556,092 input bytes

Timing and extra output metrics are calculated directly from the downloadable samples.

How to interpret the difference

A smaller or faster format is not automatically easier to operate. Field-name repetition in JSONL buys self-description, while a CSV header and documented dialect can be sufficient for stable flat exports.

For event streams, per-line JSON can isolate malformed records more naturally. For analyst-facing flat tables, CSV remains widely convenient.

Decision rules

  • Use CSV for stable, flat, spreadsheet-oriented exports with a documented dialect.
  • Use JSON Lines for stream processing and records that benefit from explicit field names and types.
  • Validate malformed-row behavior before selecting a format for long-running imports.

Fixture and measurement design

Pre-run hypothesis

CSV may be more compact for flat data, while JSON Lines carries field names and types more explicitly at a byte cost.

  1. Both fixtures represent the same 400 flat records with id, score, enabled and region fields.
  2. CSV is parsed with str_getcsv per line after a header; JSON Lines is decoded one object per line with exceptions enabled.
  3. Input bytes and median parse time are both reported.
40operations/sample
7measured rounds
2variants
Medianprimary statistic
Open measured environment
Measurement run
2026-07-22T15:23:56+00:00
PHP
8.4.23 (cli)
Operating system
Linux 4.18.0-553.85.1.el8_10.x86_64
Architecture
x86_64
Processor
AMD EPYC-Rome Processor
Reported host memory
15.02 GiB host total
CLI OPcache
0
PHP memory limit
1024M
Loaded study extensions
json, openssl, zlib, mbstring, pdo_sqlite
Timing clock
hrtime(true)
Measured rounds
7

Where this result stops

  • The CSV values do not contain embedded commas, quotes or newlines.
  • Nested records, schema evolution and compression are not included.

Primary documentation

These primary sources define the formats and APIs involved. They should be read alongside the measured host data, not replaced by it.

Use the data in another environment