Boosting JSON.stringify: How V8 Achieved a 2x Speed Boost

Introduction: The Need for Speed

JSON.stringify is a foundational JavaScript method for converting objects into JSON strings. Its performance touches nearly every web application, from sending data over the network to persisting state in localStorage. A faster JSON.stringify means snappier page loads and more responsive user interfaces. That’s why the V8 team set out to double its speed—and succeeded. In this article, we’ll uncover the technical innovations that made this leap possible, from a side-effect-free fast path to optimized string handling.

A Side-Effect-Free Fast Path

The cornerstone of the optimization is a new fast path built on a simple premise: if we can guarantee that serializing an object won’t trigger any side effects, we can use a much more efficient, specialized implementation. A side effect here includes anything that breaks the straightforward traversal of an object—not just user-defined code executed during serialization (like toJSON or getters), but also internal operations that could cause a garbage collection (GC) cycle, such as flattening a ConsString.

As long as V8 can determine that serialization is free from such effects, it stays on this highly optimized path. This allows the engine to skip many expensive checks and defensive logic that the general-purpose serializer must always perform. The result is a significant speed boost for the most common JavaScript objects—plain data containers like objects, arrays, numbers, and strings. For more on what constitutes a side effect and how to avoid them, see Limitations.

Iterative Over Recursive

The new fast path is iterative, in contrast to the recursive general-purpose serializer. This architectural choice brings multiple advantages: it eliminates stack overflow checks, allows the engine to quickly resume after encoding changes, and—most importantly—enables developers to serialize much deeper nested object graphs than before. Previously, deeply nested objects risked hitting the stack limit; now, that risk is greatly reduced.

Handling Different String Representations

Inside V8, strings can be stored in two internal representations: one-byte (for ASCII characters) or two-byte (for Unicode characters). If a string contains only ASCII characters, each character takes one byte; but if even a single non-ASCII character appears, the entire string uses two bytes per character, effectively doubling memory usage.

To avoid constant branching and type checks in a unified serializer, the team templatized the entire stringifier on the character type. This means V8 now compiles two distinct, specialized versions of the serializer: one fully optimized for one-byte strings and another for two-byte strings. While this increases binary size, the performance payoff is well worth it. During serialization, the engine must inspect each string’s instance type to detect representations that can’t be handled on the fast path (like ConsString, which might trigger a GC when flattened) and require a fallback to the slow path. This necessary check becomes much cheaper when the serializer is specialized for a known character width.

Mixed Encodings and Fast Fallbacks

When strings mix encodings (e.g., an ASCII substring within a Unicode string), the serializer handles them efficiently. The instant type inspection ensures that only the minimal number of checks occurs. If a string is not compatible with the current fast path, the engine seamlessly falls back to the general-purpose serializer, ensuring correctness without sacrificing performance for the common case.

Limitations and How to Maximize Benefits

To fully leverage the fast path, avoid constructs that introduce side effects. These include:

• Custom toJSON methods — if an object defines its own toJSON, V8 must execute it, which forces a slow path.
• Getter properties — any property accessed via a getter may execute arbitrary code.
• Proxy objects — proxies intercept property accesses and can cause side effects.
• ConsString and other non-flat string types — these may trigger GC during flattening.
• Objects with Symbol keys or non-enumerable properties — these require additional handling.

For plain data (simple objects, arrays, numbers, booleans, and strings), V8 can usually stay on the fast path. To maximize performance, ensure your serialized objects are pure data structures without custom serialization logic.

Conclusion

By introducing a side-effect-free fast path, switching to an iterative traversal, and templatizing string handling for one-byte and two-byte representations, the V8 team has more than doubled the speed of JSON.stringify. These optimizations yield faster page interactions and more efficient data serialization across the web. The improvements are available now in the latest V8 release, so your applications can benefit immediately.