JSON Parser Benchmark

What it does

Measures real JSON.parse + JSON.stringify performance on your browser’s native engine across 8 realistic document shapes: small flat (100 records), medium (10K), large (100K), deeply-nested (50 / 500 levels), big-integer-heavy, Unicode-heavy with multi-script + emoji, and long-string-heavy (200KB strings × 50). Results show median, min, max, and throughput in MB/s — downloadable as JSON for citation.

“Is JSON.parse fast enough?” gets asked constantly with no measured answer. Published numbers are dated — most articles cite V8 internals from 2017 that don’t reflect current optimizations. This page generates current numbers on demand, with reproducible methodology, on the visitor’s real browser.

How to use it

1. Click 'Run benchmark' to measure all 8 cases on your current browser.
2. Toggle individual cases under 'Choose cases' if you want to skip the largest case (100K records, ~15MB) on a slow machine.
3. Read parse and stringify medians side-by-side. Parse is usually the bottleneck.
4. Throughput (MB/s) lets you estimate how a 100MB API response will parse on this engine.
5. Click 'Download JSON' to save raw measurements with engine, hardware, and methodology metadata.

How it works

Key takeaways

• JSON throughput on V8 is typically 100-300 MB/s on object-heavy documents (lots of keys), 1-3 GB/s on long-string-heavy ones (parser is mostly memcpy). Counterintuitive but explainable: per-character cost is much lower inside a string than inside a structural token.
• JSON.parse is ~2-3× slower than JSON.stringify for the same document. Parsing is harder than serializing because you don’t know what comes next.
• Deeply-nested documents (500+ levels) parse fine in V8/SpiderMonkey/JSC at current versions. Older browsers (pre-2020) blew the stack past ~256 levels. Most production parsers limit nesting to 1024 for security.
• Big-integer documents are slow because parsing each digit string into an IEEE 754 double costs more than parsing a smaller number. Plus you LOSE precision past 2^53 — verify your ID format before sending big integers as JSON numbers.

Methodology

Each case is a deterministic JSON-string generator. Same input every run, so numbers are comparable across measurements (within a single browser version).

1. 5 warmup runs — result discarded. Lets V8 / SpiderMonkey JIT-compile the parser’s hot paths. JSON parsing is mostly C++ in modern engines (V8’s parser is hand-tuned C++, not JIT’d JS), but the JS-side wrapper still benefits from steady-state.
2. 11 measured runs — performance.now() wraps each JSON.parse(text) call. Times collected, sorted, median reported. Min/max included for variance check.
3. Stringify measured separately — same 11-run pattern. We do parse first, then stringify the parsed object. This avoids cross-cache interference where stringify might pollute parse memory.
4. 50ms inter-case delay via setTimeout — gives the browser GC a chance to clean up before the next case.

What the cases test

• flat-100 / flat-10k / flat-100k: scaling. Object-heavy documents with mixed scalar fields. Each record has 6 keys. Tests how parse time scales with document size.
• deep-50 / deep-500: nesting cost. Recursive structure with object/value alternation. Tests recursion depth handling and cache locality.
• big-numbers: numeric parser. Numbers near Number.MAX_SAFE_INTEGER (2^53) and very large floats. Each number requires multiple atoi-style operations.
• unicode-1k: escape and surrogate pair handling. Mixed Latin, CJK, Hebrew, Arabic, Cyrillic, plus emoji (BMP + supplementary plane).
• string-heavy: per-byte cost. 50 records with one 200KB string each = 10MB total. Most of the work is reading characters; structural overhead is tiny. Highest throughput case.

Cross-engine notes

V8 (Chrome / Edge / Node): hand-tuned C++ parser. The fastest for most workloads. Special optimizations for ASCII keys and small integers.

SpiderMonkey (Firefox): also C++ parser, comparable to V8 on flat documents but ~10-30% slower on deeply-nested. Stronger Unicode handling due to better support for variant string encodings internally.

JavaScriptCore (Safari): usually within 20% of V8. Historically slower on big-integer parsing; recent versions caught up.

For binary alternatives: Protocol Buffers / FlatBuffers / Cap’n Proto parse 5-50× faster than JSON because they don’t need to parse text. MessagePack / CBOR are ~2-3× faster than JSON on most documents. BSON (MongoDB) is roughly the same speed as JSON. The cost is loss of human readability and tooling.

Common mistakes when benchmarking JSON

• Reusing the same parsed object. Some benchmarks cache the parse result, then time stringify of the cached object. That’s a different workload than a fresh parse-stringify cycle — the stringify sees a hot, JIT-friendly object.
• Including JSON generation in the timed window. We generate the input strings ONCE per case before warmup; only parse/stringify is timed.
• Forgetting variable-shape effects. V8’s hidden classes optimize objects with stable key sets. Every record in our flat-* cases has the same 6 keys — that’s realistic for API responses but not for heterogeneous data. Mixed-shape records would parse 20-30% slower.
• Comparing across different machines. Throughput depends on CPU memory bandwidth and L3 cache size. A 2024 desktop is 2-3× faster than a 2020 laptop on the same browser. Always note the hardware.

When to use this tool

• You're choosing between JSON and a binary format for high-frequency or large payloads.
• You're debugging a parse-time slowdown in a real application.
• You're writing a technical article that needs measured performance data.
• You're sizing a streaming-parser switch (deciding the threshold above which JSON.parse becomes prohibitive).

When not to use it

• Production performance profiling — Chrome DevTools Performance tab on real traffic gives more accurate numbers including network and de-serialization cost.
• Comparing JavaScript JSON parsers to native parsers in other languages — JSON.parse is comparable to Python's json or Go's encoding/json, but actual speed depends on the input shape and language runtime.
• Microbenchmarking sub-millisecond cases — performance.now() resolution clamps at ~5µs and noise dominates very small measurements.

Common use cases

• Deciding whether to use streaming JSON parsers (jq, ijson, JSONStream) for a given workload size.
• Comparing parse cost between Chrome, Firefox, and Safari for a cross-browser app.
• Investigating a slow-load complaint on a JSON-heavy SPA.
• Justifying a switch to an alternative format (CBOR, MessagePack, Protocol Buffers) with measured numbers.
• Citing real parse-throughput numbers in engineering blog posts.