View, format, validate, diff, convert and generate types from JSON — all running locally. Parsing happens in a Web Worker and the tree renders only what is on screen, so document size stops deciding whether the page survives.
The common approach builds an element for every key and value in the document. At 120,000 records that is well over a million elements before the browser has painted anything. JSONic keeps a flat row model and mounts only the rows inside the viewport.
JSON.parse on a large string blocks every interaction until it finishes. Ours runs in a Web Worker, and superseded jobs are dropped by id so fast typing never renders a stale result.
There is no upload step and no server-side processing. That matters when the payload you are debugging contains production data.
Drafts autosave to IndexedDB on a debounce and when the tab hides, so closing it by accident does not cost you the document you were working through.
Above 1 MB live processing switches off; above 4 MB the editor becomes a read-only virtualized view. Guessing that a 50 MB textarea will stay responsive is what breaks other tools.
Each one is its own page, and each one runs entirely in your browser.
Three things decide whether a browser-based JSON tool survives a large file, and most online viewers get all three wrong at once.
Parsing on the main thread. Calling JSON.parse on a 40 MB string blocks the event loop for as long as it takes. Nothing repaints, no button responds, and the browser eventually offers to kill the page. Moving the parse into a Web Worker does not make it faster, but it keeps the interface alive while it runs — and lets a newer request supersede one already in flight, which is what makes live-as-you-type processing viable at all.
Rendering the whole document. A tree view that creates a component per value scales with the file rather than with the screen. Virtualization inverts that: keep the document as a flat list of rows, work out which slice of rows the viewport covers, and mount only those. Expanding a node becomes adding a path to a set, and collapsed branches are never walked at all — so a 40 MB document with everything collapsed costs about as much as an empty one.
Re-serialising to measure. Computing statistics by calling JSON.stringify at every node re-serialises the whole subtree once per node. A single traversal that counts as it goes gives the same numbers without the quadratic behaviour, and an explicit stack instead of recursion means a deeply nested document cannot overflow the call stack.
Past a certain size, the honest answer is to change what the tool offers rather than pretend. Above 1 MB, JSONic stops reprocessing on every keystroke and waits for you to press Run. Above 4 MB, the editor becomes a read-only virtualized view, because no browser keeps an editable textarea that large responsive. Being explicit about those thresholds is more useful than a spinner that never resolves.