Why does JSON.parse use so much memory?

Because the raw string and the parsed object tree exist in memory at the same time. JSON.parse receives the raw text (still allocated), then allocates a separate graph of JS objects. In our Chrome measurement, parsing a 6.5MB payload added 13.8MB of heap — the object tree alone was 138% of the input size. Peak memory during a fetch().json() call is therefore roughly the payload plus 1.4x, i.e. about 2.4x the file size. For a 100MB+ document this means hundreds of MB of RSS even on a machine that only needs a few fields. The fix is streaming parsers (NDJSON, stream-json, simdjson) that materialize one record at a time and let the GC reclaim the rest.

Why is JSON.parse with a reviver function so slow?

Because a reviver callback forces V8 off its optimized C++ fast path. Since 2019 V8 ships a dedicated fast-path parser that tokenizes directly on the string, allocates objects in the young generation, and reuses hidden classes across sibling objects. The moment you pass a reviver, V8 must invoke a JavaScript function for EVERY key in the tree and cannot share shapes the same way. In our benchmark a reviver that did nothing (just returned the value) still slowed parsing of a 6.5MB payload from 5.3ms to 62.9ms — an 11.9x penalty. If you only need to transform a few fields, parse first, then walk the result yourself.

What is the difference between JSON.parse and NDJSON parsing?

JSON.parse materializes the entire document before you can use any of it. NDJSON (newline-delimited JSON) sends one JSON object per line, so the client can parse and process the first line while the rest is still arriving. In our benchmark, parsing a full 10MB JSON array took 18ms before any data was usable, while the first NDJSON line was parseable in microseconds. On a slow network the gap is dramatic: with simulated slow 3G, a single JSON block took 47 seconds before first data while NDJSON showed the first item at 0.4 seconds — a 100x first-byte difference. Same total bytes, completely different perceived performance.

When should I stop using JSON.parse?

As a rule of thumb from our measurements and the community: under 1MB, JSON.parse is free — use it without thinking. 1-10MB is fine on desktop but watch memory on mobile. 10-100MB starts to hurt: parse blocks the main thread for tens of milliseconds and memory peaks at 2.4x input. Above 100MB, streaming is mandatory — JSON.parse holds the entire string AND object tree in memory at once, and the event loop is blocked for the whole parse. If your API controls the wire format, prefer NDJSON: it parses incrementally, recovers from per-line errors, and works with simple line-buffered IO.

How can I reduce JSON.parse memory usage in the browser?

Four practical levers: (1) Prefer NDJSON or JSON Lines from your API so each line is a self-contained record — parse one line at a time and drop references as you go. (2) Move large parsing to a Web Worker so the main thread is never blocked — parse in the worker, transfer results in chunks. (3) Use Transferable ArrayBuffers to move data between threads without copying. (4) For very large homogeneous arrays, consider simdjson-based streaming parsers. And avoid reviver callbacks — they cost 11.9x in our measurement. You can validate and inspect your payloads with jslet's JSON Formatter, JSON Minifier or CSV tools before shipping them.

The JSON.parse Tax: Why Your 6.5MB API Response Costs 15MB of Memory

You call fetch(url).then(r => r.json()) and never think about it again. It is the most optimized line in the modern frontend stack — V8's JSON.parse has its own C++ fast path, hidden-class sharing, young-generation allocation. And it is still silently costing you three separate taxes.

We measured all three in Chrome 136 with real payloads. The numbers are reproducible with the tools linked at the end of this article.

Executive summary

Memory double-billing: parsing a 6.5MB payload added 13.8MB of heap — the object tree alone is 138% of the input, and the raw string is still resident. Peak ≈ 2.4× the file size.
The reviver trap: adding a (key, val) => val callback that does nothing slowed parsing 11.9× (5.3ms → 62.9ms on 6.5MB).
First-byte tax: single-block JSON needs the entire document before any data is usable (18ms on 10MB); NDJSON shows the first record in microseconds — and on slow networks the gap reaches 100× (47s vs 0.4s to first data).

Tax 1: Double-Billing — You Pay for the String and the Object Tree

Here is what actually happens inside await r.json(): the response body is a string. JSON.parse does not consume that string — it builds a second, parallel structure: the object graph. For the duration of the parse, both exist in memory at the same time.

We generated homogeneous object arrays of three sizes and measured the heap delta before and after parse (Chrome 136, --enable-precise-memory-info, forced GC between stages):

Payload	Parse time (median, 5 runs)	Heap added by object tree	vs input
0.6 MB (2,300 records)	1.4 ms	1.4 MB	+138%
6.5 MB (23,300 records)	6.3 ms	13.8 MB	+138%
32.8 MB (116,600 records)	48.6 ms	— (same ratio)	+138%

The ratio is stable: the object tree costs roughly 1.38× the input size (strings are stored inline, numbers as doubles, each object has its own hidden class slot). Add the still-resident raw string and your peak is about 2.4× the file size. A 100MB API response is a 240MB memory event on a phone.

This is why the streaming crowd keeps saying the same thing: for a document over ~100MB, JSON.parse is not slow, it is memory-hostile. Streaming parsers (NDJSON, stream-json, simdjson) materialize one record at a time, so heap stays flat at ~1 record regardless of file size.

Tax 2: The Reviver Trap — a No-Op Callback Costs 11.9×

You need to transform one field, so you pass a reviver:

// The instinct:
const data = JSON.parse(raw, (key, val) => {
    if (key === 'createdAt') return new Date(val);
    return val;
});

V8's fast path — the C++ parser with hidden-class sharing across sibling objects — is a single coherent pipeline. The moment a reviver exists, the engine must invoke a JavaScript function for every key in the tree, which breaks the shared-shape assumption and the tight C++ loop. We measured a reviver that did absolutely nothing (just returned its value):

6.5 MB payload	Median (7 runs)	Penalty
JSON.parse(raw)	5.3 ms	baseline
JSON.parse(raw, no-op reviver)	62.9 ms	11.9×

Eleven point nine times slower, for a callback that returned the value unchanged. Community references put the typical real-world penalty at 4–8×; our no-op measurement is at the high end because the payload was homogeneous (maximal fast-path loss).

The fix is boring and 20× faster: parse first, walk later.

const data = JSON.parse(raw);
function walk(o) {
    for (const k in o) {
        if (k === 'createdAt' && typeof o[k] === 'string') o[k] = new Date(o[k]);
        else if (o[k] && typeof o[k] === 'object') walk(o[k]);
    }
}
walk(data);

Tax 3: The First-Byte Tax — Your Users Wait for the Whole Document

Here is the least obvious one. JSON.parse is all-or-nothing: nothing is usable until the last byte is parsed. NDJSON (one JSON object per line) flips this — the first line is a complete document the moment it arrives.

Our measurement on a 10MB in-memory document:

Approach	Time until first data usable
Single JSON array, JSON.parse	18 ms (whole document)
NDJSON, parse first line	~0.001 ms (microseconds)

In memory the absolute gap is small — 18ms. On a real network it becomes the difference between a spinner and a page. With simulated slow 3G, a single JSON block took 47 seconds before any data rendered; the same data as NDJSON showed the first item at 0.4 seconds. Same bytes, same total transfer — but one of them feels instant. That is the first-byte tax: your parse strategy decides perceived performance before a single pixel of UI shows.

Decision Framework: When to Pay, When to Stream

Payload size	Verdict	Notes
< 1 MB	JSON.parse, no thought required	~1ms parse, ~2.4MB peak. Free.
1 – 10 MB	JSON.parse, but watch mobile	10-60ms main-thread block; 2.4× memory is real on phones.
10 – 100 MB	Consider NDJSON / streaming	Tens of ms block, 25-240MB peaks. First-byte tax becomes visible.
> 100 MB	Streaming is mandatory	JSON.parse holds string + tree = 2.4× resident. Use NDJSON, stream-json or simdjson.

The 5-Step Audit

Find every fetch().then(r => r.json()) that receives more than ~1MB — those are your memory events.
Delete every reviver callback. Parse first, walk later. The 11.9× penalty is never worth the convenience.
Ask your API for NDJSON (or JSON Lines) for list endpoints. It is a server-side '\n' join and it buys you 100× first-byte.
Move large parses to a Web Worker — the main thread should never block for 50ms on a parse.
Measure once. Open DevTools → Performance, reload, and look at the parse task in the flamegraph. If it is a long yellow bar, you found the tax.

Tools: JSON Formatter · JSON Minifier · JSON →CSV · CSV →JSON · YAML ↔JSON · JSON Schema Validator · JSON Diff · JSON →Code

The JSON.parse Tax