Deep Dive: V8's JSON.stringify Optimizations and Deterministic Output

JavaScript's JSON.stringify is fundamental for web developers – from APIs to configuration – yet its performance and output order have subtle implications. Recently, the V8 engine (in Chrome and Node.js) has reworked JSON.stringify to be dramatically faster (often >2× faster on benchmarks). Alongside this speedup, there's growing interest in the determinism of the JSON output.

In this deep dive, we explore how JSON.stringify worked before (its key-order rules and bottlenecks), detail V8's new insertion-order-based serialization and fast-path optimizations, and show real performance gains. We'll illustrate code examples, discuss where deterministic output matters, compare to third-party serializers, and provide practical advice for using JSON.stringify at scale.

Traditional JSON.stringify in V8

By ECMAScript specification, JSON.stringify(obj) iterates object keys in a defined order: all integer-like keys first (in ascending numeric order), then the remaining string keys in insertion order.

let o = {};
o[2] = 2;
o.a = 3;
o.b = 4;
o["1"] = 1;
console.log(JSON.stringify(o));
// {"1":1,"2":2,"a":3,"b":4}
 
let obj1 = {a: true, b: true};
let obj2 = {b: true, a: true};
console.log(JSON.stringify(obj1), JSON.stringify(obj2));
// {"a":true,"b":true} vs {"b":true,"a":true}

The first example sorts keys ("1","2") numerically before ("a","b"), per spec. The second shows two objects with the same keys in different insertion order yielding different strings; this is expected since insertion order of string keys is preserved.

Key takeaway: For a given object, the output is deterministic if the property insertion order is fixed; however, two separately constructed but identical objects may stringify differently if their keys were added in a different sequence.

Under the hood, V8's old JSON.stringify used a straightforward recursive algorithm. It would traverse the value graph, recurse into objects and arrays, and build a single growing buffer for the result. Each time the buffer needed to grow, V8 would reallocate a larger C++ heap buffer and copy the existing characters – a costly step for large JSON. Also, every character in a string was scanned one by one to check if it needed escaping, and large strings or big numeric arrays would be relatively slow to serialize.

The New Side-Effect-Free Fast Path

To address these challenges, V8 13.8 (Chrome 138) introduced a fast path for JSON.stringify that applies when there are no custom side effects or formatting requests.

Fast-path conditions

The call must have:

• No replacer or space parameter – adding either immediately forces the generic serializer
• Ordinary plain-data objects or arrays with no overridden .toJSON()
• No indexed (numeric-like) properties (e.g. treating objects as arrays by adding keys "0","1",...)

Essentially, the fast path assumes "data-only" objects and arrays.

Under these conditions, V8 switches to a new iterative algorithm (instead of recursive) and bypasses many checks. This has two big effects:

1. No more stack overhead (so extremely deep nesting is now safe)
2. Fewer per-property/per-value tests

For example, the first time an object is serialized, V8 records its hidden class information. If subsequent objects have the same hidden class (common when you serialize an array of similar objects), V8 can use an "express lane" and copy the keys without re-checking them.

In practice: For an array of 10,000 user objects with the same shape, after the first one, V8 reuses that shape info on the rest.

If any of the fast-path conditions fail, V8 "falls back" to the slow, general-purpose path – ensuring correctness at the cost of performance.

Enjoyed this post? Follow on LinkedIn for more engineering insights.

String and Number Optimizations

Even on the fast path, V8 applied further micro-optimizations:

One-byte vs two-byte strings

V8 recognizes that many JSON strings are pure ASCII. It compiles two specialized stringifiers – one for 1-byte characters and one for 2-byte (UTF-16) strings. If a string has no high code-point characters, V8 uses the faster 1-byte routine; if any non-ASCII appears, it switches seamlessly to the 2-byte routine.

SIMD/SWAR for escaping

Scanning a string for escapable chars (", \n, etc.) is a hotspot. The new implementation does this in bulk: for long strings it employs hardware SIMD instructions to check many bytes at once, and for shorter strings it uses SWAR (SIMD Within A Register) bit-twiddling. Most strings (with few or no escapes) can be copied in larger chunks.

Dragonbox for numbers

Converting numbers (floats) to decimal strings used to rely on V8's Grisu3 algorithm with occasional slow fallback cases. V8 has replaced this with the new Dragonbox algorithm. Dragonbox is faster and handles all ranges without fallback, so numeric serialization is smoother.

Segmented Output Buffer

A final improvement was in how V8 builds the output string:

• Old approach: One contiguous buffer growing on demand. Every time it filled up, V8 allocated a new, larger buffer and copied the whole string – an O(n) copy for each resize.
• New approach: A segmented buffer. V8 writes into fixed-size chunks. When one chunk is full, it allocates the next. Only at the very end are all chunks concatenated into one string.

This completely eliminates the repeated copying overhead on large JSON outputs.

Performance Benchmarks

The net effect of all these changes is striking. V8 reports >2× speedups on JSON-heavy benchmarks. For example, the JetStream2 "json-stringify-inspector" test shows over twice the throughput in Chrome 138 / V8 13.8 vs older versions.

Third-party serializers sometimes outperform built-in JSON on small data. For instance, fast-json-stringify (which uses a precompiled schema) can be faster on tiny objects, but native JSON wins on larger arrays:

With V8's new optimizations, the built-in JSON.stringify is competitive across many cases.

Real-World Use Cases for Determinism

Deterministic output (same string for the same data) is critical in several contexts:

Caching and memoization

Developers often use JSON.stringify(obj) as a cache key. If two logically identical objects produce different JSON (due to key order), the cache will miss. Ensuring consistent order means the same object graph always hits the same cache entry.

Hashing and signatures

When hashing or signing JSON data (for integrity or crypto), you need a canonical string. RFC 8785 ("JSON Canonicalization Scheme") explicitly defines sorting object properties deterministically so that digital signatures or content hashes match.

Reproducible builds

Tools that emit JSON (lock files, manifests, asset lists) want bit-for-bit reproducibility. A stable key order means two builds with the same inputs yield identical JSON.

Logging and diffs

In distributed systems or testing, comparing JSON payloads assumes a stable order. Deterministic serialization reduces spurious differences.

Comparison with Third-Party Solutions

For extreme performance, schema-based serializers exist. fast-json-stringify requires you to provide a JSON Schema and generates a tailor-made stringify function. It can be much faster on small objects, but the gain shrinks for large, dynamic data.

For deterministic ordering, libraries like json-stable-stringify or json-stringify-deterministic sort object keys during serialization:

const stringifyDet = require('json-stringify-deterministic');
console.log(stringifyDet({c:8, b:[{z:6,y:5,x:4}, 7], a:3}));
// => {"a":3,"b":[{"x":4,"y":5,"z":6},7],"c":8}

These libraries guarantee that two semantically equal objects produce the same JSON text, ideal for hashing or signing. The downside is extra overhead from sorting keys.

Practical Tips and Caveats

Stay in the fast lane

• Avoid replacers or formatting in performance-critical code
• Even a single space argument (JSON.stringify(obj, null, 2)) will divert to the slow path
• Use pretty JSON only for debugging

Plain objects/arrays

• Ensure your data is plain
• Don't rely on custom prototype .toJSON() if you care about speed
• Avoid proxies or getters that might have side effects

Numeric keys

• If you want the fast path, don't treat objects as sparse arrays
• Use an actual Array for index-based data, not an object with keys "0","1",...

Versions matter

These optimizations landed in V8 v13.8. To benefit, use:

• Chrome 138+
• Node.js 22+
• Electron with Chromium 138+

Character encodings

If your JSON data includes lots of Unicode (non-ASCII) in values, V8 will take the 2-byte string path, which is slightly more work. Pure ASCII strings are cheaper.

Large outputs

If you need gigabytes of JSON, the segmented buffer helps performance, but the final string is still built in memory. Consider streaming approaches if you can't hold the whole string at once.

Internal Flow Diagram

This diagram highlights the bifurcation between the fast path and general path. Only when conditions are right (no replacer/space, plain data) do we go into the optimized, iterative fast path. That path further splits: if the object's hidden class is already marked (same shape seen earlier), we jump to the express lane and skip most work.

Conclusion

V8's JSON.stringify optimizations represent a significant step forward in JavaScript performance. The combination of fast-path detection, iterative algorithms, SIMD string processing, improved number conversion, and segmented buffering delivers substantial real-world performance gains.

For most developers, simply upgrading to a modern V8 version (Chrome 138+, Node.js 22+) will automatically provide these benefits with no code changes required. The key is understanding when the fast path applies and structuring your data accordingly.

While third-party serializers still have their place for specialized use cases, V8's improvements make the built-in JSON.stringify competitive for the vast majority of applications. Focus on writing clean, predictable code with plain objects and arrays, and let V8's optimizations handle the performance heavy lifting.