Compact vs pretty-printed JSON: CPU cost and transfer-size trade-off
A repeatable comparison of compact and human-readable JSON encoding using the same nested application payload.
The choice this benchmark informs
How much processing time and output size does pretty printing add when a PHP application serializes a medium nested payload?
APIs usually optimize for transfer size and machine parsing, while audit artifacts and checked-in fixtures benefit from readability.
The meaningful decision is not simply which variant is faster. It is whether readability is worth the extra bytes and any measurable CPU cost in the intended delivery path.
Result and trade-off
What this run shows: Compact JSON used the least CPU time in this encoding fixture; the output-byte column decides whether that gap matters for delivery. The slowest-to-fastest median spread was 26.94% on the measured host.
| Variant | Median | Middle 50% | Operations/s | Additional measure |
|---|---|---|---|---|
| Compact JSONFastest | 225.36 µs | 225.06 µs–232.09 µs | 4,437 | 67,457 output bytes |
| Pretty JSON | 286.06 µs | 278.64 µs–289.80 µs | 3,496 | 135,058 output bytes |
Timing and extra output metrics are calculated directly from the downloadable samples.
How to interpret the difference
The timing table should be read together with output_bytes. A small runtime difference can become irrelevant when responses are cached, while a size increase repeats on every uncached transfer.
Compact JSON is the defensible default for APIs and machine-to-machine delivery. Pretty JSON remains appropriate for downloadable examples, debugging snapshots and files that humans are expected to inspect directly.
Decision rules
- Use compact output for production API responses unless a documented client requirement says otherwise.
- Offer pretty output as an explicit debug or download option instead of making it the default response form.
- Measure again with compression enabled before treating raw byte differences as network-byte differences.
Fixture and measurement design
Pretty printing should produce a larger document and may add modest encoding work, but the operational importance depends on whether the file is for humans or network transfer.
- The source payload contains 400 nested records with numeric, Boolean, Unicode, list and metadata fields.
- Both variants use the same Unicode and slash-handling flags. The only material encoding difference is JSON_PRETTY_PRINT.
- Each measured sample performs the complete encoding operation repeatedly; the reported value is the median nanoseconds per operation across rotated rounds.
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 payload shape is representative, not universal; deeply nested or string-heavy documents can behave differently.
- This study measures encoding only. Network compression, TLS, buffering and client parsing are outside its scope.
Primary documentation
These primary sources define the formats and APIs involved. They should be read alongside the measured host data, not replaced by it.