A 100 MB JSON file is not an unusual thing to have on a laptop in 2026 - a database export, a day of application logs, a bulk API dump. Opening one in a typical browser-based JSON tool is a different story. The tab either locks up for the better part of a minute, the page shows “Aw, Snap!” and reloads itself, or it opens but scrolling the result feels like dragging a spreadsheet through mud. None of that is inherent to the file. It’s a consequence of how most tools are built.
Where the time and memory actually go
Three things happen when a typical JSON viewer opens a file, and each one scales badly with size.
Parsing into a full object tree. JSON.parse is fast, but it builds a complete JavaScript object graph in memory - every string, every number, every nested object as a real allocated object. For a 100 MB file, that in-memory representation can end up several times larger than the file itself, and building it happens synchronously on the same thread that’s supposed to keep the page responsive.
Rendering every node as a DOM element. A tree view that creates a real <div> or <li> for every key and value in the document is fine for a few thousand nodes. A 100 MB file can easily contain a few million. Browsers were not built to lay out and paint that many elements at once, and the tab will visibly stall trying.
Blocking the main thread. Both of the above usually happen on the same thread that handles scrolling, clicking, and repainting the page. If parsing takes 8 seconds, the tab is unresponsive for 8 seconds - no scroll, no click, sometimes a “page unresponsive” browser warning.
The three techniques that actually fix it
Parse off the main thread, using typed arrays instead of a full object tree. Running the parser in a Web Worker keeps the page interactive while parsing happens in the background. Using typed arrays (or an equivalent compact representation) instead of a full JavaScript object graph cuts both the memory footprint and the time spent allocating objects the user may never even scroll to.
Virtualize the tree. Instead of creating a DOM element for every node in the document, render only the rows currently inside the visible scroll area, and recycle those same DOM elements as the user scrolls. A 2-million-node array and a 20-node array cost the same to render this way, because the number of real DOM elements never grows past what fits on screen.
Parse and render iteratively, not recursively. This one is about depth rather than raw size, but the two often come together in real files. A recursive parser or renderer adds a stack frame per level of nesting; a document nested a few thousand levels deep can overflow the call stack regardless of how small it is in bytes. Walking the document with an explicit stack instead of function calls avoids that failure mode entirely.
What this looks like in practice
Jsontify’s large JSON viewer is built around these three techniques specifically because file size is where most competing tools fall over. In concrete terms: a 1 MB file parses in well under 100 ms, a 10 MB file in under a second without blocking the main thread for more than about 50 ms at a stretch, and files up to 100 MB stay scrollable with a progress indicator instead of crashing the tab.
As with every other feature here, this happens entirely on your side: parsing and rendering run in your browser, in a Web Worker on your device - nothing is uploaded to our servers, whether the file is 10 KB or 100 MB.
A quick way to tell if a tool will handle your file
If you’re evaluating any JSON tool (not just this one) against a large file, three quick questions predict the outcome better than the marketing copy does: does it say anywhere that parsing runs off the main thread, does the tree view mention virtualization or windowing, and does opening a large sample file actually keep the scroll and the UI responsive while it loads. If the answer to all three is yes, the tool was built with large files as a real constraint rather than an afterthought.