Paste a 200 KB JSON response into most online formatters and it opens instantly. Paste a 5 MB export and the same tool can take several seconds, or stop responding entirely. That’s not a coincidence or a fluke on a particular file - it’s a predictable consequence of a handful of implementation shortcuts that work fine at small scale and stop working at large scale. Here’s what they are and why they matter.
Shortcut 1: parsing on the main thread
JSON.parse(text) is a single blocking call. Run it directly in a click handler or a page-load script, and the browser’s main thread - the same thread responsible for scrolling, redrawing, and responding to input - is fully occupied until it finishes. For a small file that’s a few milliseconds, invisible to the user. For a 20 MB file it can be a full second or more of the page not responding to anything, which reads as a freeze even though the tab technically hasn’t crashed.
The fix isn’t a faster parser - JSON.parse is already implemented in native code and is genuinely fast. The fix is running it somewhere else: a Web Worker, which executes JavaScript on a separate thread and only hands the result back to the main thread once it’s ready, so the page stays interactive the entire time.
Shortcut 2: building the full tree, twice
Many tools parse the text into a JavaScript object with JSON.parse, and then build a second, separate tree data structure from that object to drive the UI (expand/collapse state, line numbers, node metadata). That’s two full passes over the data and two in-memory representations, when the actual UI only needs to reference small pieces of the source at any given moment. The alternative is a single pass that produces a compact structure - something closer to a set of typed arrays than a nested object graph - that the UI reads from directly, with the display layer only materializing detail for a node when a user actually looks at it.
Shortcut 3: one DOM element per node, always
This is the one that causes the most visible lag. A tree component that renders a <div> for every key-value pair, unconditionally, works great in a demo with a 50-line JSON sample. Point the same component at an array with 500,000 elements and the browser has to create, lay out, and paint 500,000 DOM nodes before the page becomes usable - even though at most a few dozen of them are ever visible on screen at once.
Virtual scrolling (sometimes called windowing) fixes this by only rendering the rows currently inside the viewport, plus a small buffer, and reusing those same DOM elements as the user scrolls. The perceived result is a tree that feels equally fast whether it has 50 nodes or 5 million, because the actual DOM never grows past a few dozen elements.
Shortcut 4: recursive parsing and rendering
Less visible than the other three, but it causes a different kind of failure: a crash instead of a slowdown. A parser or a tree-building function that calls itself once per level of nesting will overflow the browser’s call stack on a sufficiently deep document - sometimes at a few thousand levels, well within range for deeply nested API responses or generated config files. This is a depth problem, not strictly a size problem, and it can happen on a file that’s tiny in bytes but nested very deep. An iterative implementation, using an explicit stack instead of function-call recursion, has no such ceiling.
What to look for instead
None of these four fixes are exotic - Web Workers, virtual scrolling, and iterative algorithms are all standard, well-documented techniques. The reason so many JSON tools skip them is that they’re extra implementation work for a case (large files) that doesn’t show up until a user actually hits it. Jsontify’s large JSON viewer was built with all four from the start, specifically because “the file is bigger than a typical API response” is a normal case for the people who reach for a tool like this, not an edge case worth skipping.
Everything above happens locally regardless of file size: parsing and rendering both run in your browser, in a Web Worker on your device - nothing is uploaded to our servers, whether you’re opening a 2 KB config snippet or a 90 MB export.