How to benchmark a large JSON viewer in Chrome

Define the input shape first

Large JSON is not one workload. A root array with many small records, one huge string value, a deeply nested object, a JSONL stream normalized to an array, and a high-cardinality export source can stress different systems.

Before measuring, record the exact generator, seed, byte size, record count, maximum record size, nesting depth, and whether the source is strict JSON, JSONC, JSONL, NDJSON, or another supported JSON-family format.

{
  "fixture": "orders-root-array-10gib.json",
  "generator": "scripts/generate-large-orders.mjs",
  "seed": "2026-09-04-a12",
  "bytes": null,
  "records": null,
  "maxRecordBytes": null,
  "format": "json",
  "notes": "Fill after generating and hashing the fixture."
}

Record the environment

A Chrome benchmark without environment details is anecdote. Record operating system, CPU, memory, storage type, Chrome version, extension version, profile mode, file access setting, network route if HTTP is used, and whether any other extensions are enabled.

Use a clean profile for benchmark runs. If you compare file://, file picker, and HTTP routes, label them separately. They are different acquisition paths and can produce different browser-side behavior.

Measure phases separately

Separate the benchmark into phases instead of one vague loaded/not-loaded number. Track first visible UI, completed ingestion, first tree navigation, direct search, broad search, JSONPath, JQ, export, copy, and download. Each phase answers a different user question.

Keep raw timestamps or event logs beside any chart. If a screen recording is edited for pacing, use the log rather than the video as the timing source.

Separate memory and storage metrics

Process memory, JavaScript heap, OPFS or persistent storage size, downloaded bytes, decoded bytes, and output artifact bytes are different measurements. Label them separately and avoid using one heap snapshot as proof for every operation.

For Chrome, also distinguish the source page, extension renderer, service worker, and any worker process when the tools available to you allow it. If a metric cannot be collected reliably, say so rather than filling the table with guesses.

{
  "runId": "a12-release-001",
  "phase": "first-visible-ui",
  "route": "file-picker",
  "elapsedMs": null,
  "jsHeapBytes": null,
  "processMemoryBytes": null,
  "opfsBytes": null,
  "notes": "No value until measured from the release run."
}

Explain architecture and limits

A credible benchmark explains why the phases differ. For JSON All-in-One, source routing, incremental decoding, canonical UTF-8 streams, OPFS-backed artifacts, worker-based tasks, lazy rendering, and operation-specific outputs can all affect what the user sees.

Limits belong in the benchmark too. One giant record can be worse than many small records. Recursive queries can be expensive. Sorting and export may need different intermediate data than collapsed viewing. Failed or aborted runs should be reported, not erased.

• Read the beginner large-file workflow

Compare under matching conditions

Only compare other tools if the same fixture, machine, Chrome version or app version, source route, warm-up rules, and phase definitions are documented. If those conditions are not met, publish a single-product case study instead.

A fair comparison also respects product differences. A command-line tool, browser extension, desktop app, and online converter may make different tradeoffs about privacy, storage, streaming, rendering, and output formats.

Use the results carefully

Leave a cell blank when you did not measure it. Mixing measured values with guesses makes the table less useful than no table at all.

Historical internal diagnostics can help choose what to measure. Copy them into a benchmark report only when you can reproduce the fixture, environment, route, phase definition, and raw result. For the practical inspection workflow, return to Open large JSON files in Chrome.