Performance and Security FAQ: Slow, Janky, and Untrusted Data

Bottom line: diagnose by symptom first — parsing, rendering, or memory — then work through the fix order: cut the data volume, stop deep cloning, move parsing into a Worker with virtual scrolling, and stream anything above 50 MB. For untrusted input, cap size and nesting depth before filtering __proto__, constructor and prototype.

"JSON is slow" is inaccurate nine times out of ten; what is actually slow is usually rendering, deep cloning, or the wrong order of operations.

1. Why it is slow

Parsing a large JSON file is slow. How do I optimize it?

Locate the bottleneck first, talk about optimization second. The stages differ by several orders of magnitude:

So the optimization order should be:

1. Reduce the data volume: make the API paginate, return only the fields that are needed, and enable gzip/brotli;
2. Avoid deep cloning: see the next section; this is the most common hidden cost;
3. Lazy rendering: in the tree view render only the expanded levels instead of generating tens of thousands of DOM nodes at once;
4. Streaming: do not parse everything at once when the data exceeds 10 MB.

If the bottleneck really is JSON.parse, that means the data is already tens of MB or more, and the right move is a streaming parser:

复制import { parser } from 'stream-json';
import { streamArray } from 'stream-json/streamers/StreamArray';

// Handle array elements one by one; memory usage is independent of the total size
const pipeline = fs.createReadStream('big.json')
  .pipe(parser())
  .pipe(streamArray());

pipeline.on('data', ({ value }) => {
  processItem(value);
});

A JSON of tens of MB crashes the browser as soon as it opens. What now?

First confirm whether it "crashes" or "freezes". The two need completely different handling:

• Freeze: the tab shows "Page unresponsive" and may recover after tens of seconds. The cause is long tasks saturating the main thread;
• Crash: the tab turns into "Aw, Snap", usually memory exhaustion (OOM).

Either way, do not process it on the main thread. Move parsing into a Web Worker:

复制// worker.js
self.onmessage = (event) => {
  const parsed = JSON.parse(event.data);
  self.postMessage(parsed);
};

A Worker solves "the UI does not freeze", not the memory ceiling. A browser tab typically has 1–4 GB available; a 200 MB JSON parsed into objects can occupy 1 GB or more (every key-value pair carries object overhead), and with rendering on top it easily hits the limit.

The real solution is to never load it all:

Is JSON.parse(JSON.stringify(obj)) a deep clone?

It is a deep clone, but it "silently changes data" in several places, so it is not suitable as a general cloning tool.

复制const source = {
  date: new Date(),
  fn: () => {},
  undef: undefined,
  nan: NaN,
  map: new Map(),
  nested: { a: 1 },
};
JSON.parse(JSON.stringify(source));
// {
//   date: "2026-10-30T03:00:00.000Z",  // Date becomes a string
//   nan: null,                          // NaN becomes null
//   nested: { a: 1 }                    // only this level is correct
// }
// fn and undef disappear, map becomes {}

The list of problems:

Modern browsers have structuredClone, which supports Date, Map, Set, and circular references but not functions:

复制const copy = structuredClone(source);

If it is only a shallow config merge, the spread operator is the cheapest option: { ...config, timeout: 3000 }.

Why is expanding the tree view so janky?

Because every node is a DOM element, and once the node count reaches tens of thousands the browser's layout cost explodes.

A 10 MB JSON can contain 50k–100k leaf nodes. Even if you render only the visible area, constructing the DOM once takes hundreds of milliseconds to seconds, and every subsequent scroll triggers a reflow.

The right approach:

1. Virtual scrolling: render only the few dozen rows inside the viewport and reuse DOM nodes while scrolling;
2. Collapse by default: expand only the first two levels and render deeper levels on demand;
3. Limit the render scale: above 10k nodes, show "Data too large, use search to locate it" instead of forcing a render.

This is also why the editor on this site degrades gracefully for large files — not because it technically cannot render them, but because rendering them would be unusable.

2. Why it gets attacked

How does __proto__ injection work?

Prototype pollution. An attacker constructs JSON with a __proto__ key; if your code merges it into an object without filtering, it overwrites Object.prototype and affects every object in the runtime.

复制const payload = JSON.parse('{"__proto__": {"isAdmin": true}}');

// Dangerous code: recursive merge without checking key names
function merge(target, source) {
  for (const key in source) {
    if (typeof source[key] === 'object') {
      target[key] = target[key] || {};
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

merge({}, payload);
({}).isAdmin;  // true — every object has been polluted

The key fact: JSON.parse itself does not pollute the prototype; {"__proto__": ...} parses into an ordinary own property. What is dangerous is merging, assignment, Object.assign, lodash.merge, and similar operations after parsing.

Three defenses:

1. Filter key names: skip __proto__, constructor, and prototype when merging;
2. Use Object.create(null) as the container so there is no prototype chain to pollute;
3. Use a Map to store untrusted key-value pairs.

复制function safeMerge(target, source) {
  for (const key of Object.keys(source)) {
    if (key === '__proto__' || key === 'constructor' || key === 'prototype') {
      continue;
    }
    const value = source[key];
    if (value && typeof value === 'object' && !Array.isArray(value)) {
      target[key] = safeMerge(target[key] ?? {}, value);
    } else {
      target[key] = value;
    }
  }
  return target;
}

Also note that for...in walks inherited properties; Object.keys() is safer.

What should I watch out for when parsing untrusted JSON?

Do it in this order — low cost, high payoff:

1. Cap the size: reject anything over the threshold immediately, without reading it into memory first;
2. Cap the depth: a JSON nested hundreds of levels deep can overflow the stack of a recursive parser;
3. Cap the key count: prevents hash collision attacks and memory amplification;
4. Filter dangerous keys: __proto__, constructor, prototype;
5. Validate the structure: run it through a Schema to confirm types and required fields;
6. Do not trust Content-Type: the declared type and the actual content may disagree.

A depth check is cheap; you can use a rough regex filter before parsing, or traverse after parsing:

复制function measureDepth(value, depth = 0) {
  if (value === null || typeof value !== 'object') {
    return depth;
  }
  let maxDepth = depth;
  for (const key of Object.keys(value)) {
    maxDepth = Math.max(maxDepth, measureDepth(value[key], depth + 1));
  }
  return maxDepth;
}

But this code is itself recursive and may still overflow the stack on maliciously deep data. The safe approach is to enforce the limit during parsing, using a parser that supports a depth option (some libraries provide a maxDepth parameter).

How does XSS through JSON happen?

JSON itself is not HTML and does not execute. XSS happens at the point where "a JSON value is concatenated into HTML".

Three common paths:

The third is the subtlest. JSON.stringify does not escape <, so data containing </script><script>alert(1)</script> can close the script tag early:

复制const data = { name: '</script><script>alert(1)</script>' };
// Output: <script>var d = {"name":"</script><script>alert(1)</script>"}</script>

The fix is to convert dangerous characters into Unicode escapes:

复制function safeJsonForHtml(data) {
  return JSON.stringify(data)
    .replace(/</g, '\\u003c')
    .replace(/>/g, '\\u003e')
    .replace(/&/g, '\\u0026')
    .replace(/\u2028/g, '\\u2028')
    .replace(/\u2029/g, '\\u2029');
}

Should I limit nesting depth?

Yes. This is one of the defenses with the best cost-benefit ratio.

The consequences of not limiting it: recursive functions overflow the stack, JSON.parse crashes on some implementations when the depth is too great, and serialization blows the stack in the same way. A 1 KB [[[[...]]]] is enough to take down an unprotected parser.

A reasonable threshold depends on the business:

What is JSON hijacking?

A historical vulnerability: early browsers allowed cross-origin <script src> to load and execute JSON, and attackers stole data by redefining the Array constructor or Object.prototype.__defineSetter__.

Modern protections are fairly complete:

• Browsers no longer allow hijacking array literals with __defineSetter__;
• A correct Content-Type: application/json prevents script execution;
• X-Content-Type-Options: nosniff prevents MIME sniffing.

Older systems still carry residual risk. Practical advice: use an object at the top level, not a bare array. A wrapper such as {"data": [...]} keeps the response from being a valid JavaScript statement ({ is treated as a code block), blocking hijacking at the syntax level.

What are the risks of logging JSON?

Three:

1. Sensitive information written to disk: phone numbers, ID numbers, tokens, and plaintext passwords land in the logging system, which usually has looser permissions and longer retention;
2. Log injection: a JSON value containing newlines and forged log prefixes splits one record into several and pollutes the audit trail;
3. Size explosion: writing an entire 10 MB response into the log fills the logging system quickly.

Approach:

复制// Redact and truncate before logging
function safeLog(data) {
  const cloned = structuredClone(data);
  for (const key of ['password', 'token', 'idCard', 'phone']) {
    if (key in cloned) cloned[key] = '***';
  }
  const text = JSON.stringify(cloned);
  return text.length > 2000 ? text.slice(0, 2000) + '...(truncated)' : text;
}

Structured logging systems (such as pino) escape newlines themselves, but redaction and truncation are still your job.

3. Quick reference