How JSON Forge opens 25 MB JSON files
Last updated: 30 October 2026
Most online JSON viewers slow down or freeze on big files. JSON Forge is built to stay usable on them. This page shows measured numbers, how it works, and, just as important, what it does not fix yet. Everything here can be reproduced with a script in the open-source repository.
Results
Median of 3 runs per size on one machine: AMD Ryzen 5 7500F (6 cores, 12 threads), 32 GB RAM, Windows 11, Google Chrome (stable). Run on 30 October 2026 against the static build.
| File size | Shown as valid | First tree rows | Longest main-thread pause |
|---|---|---|---|
| 1 MB | 129 ms | 136 ms | 64 ms |
| 5 MB | 496 ms | 499 ms | 311 ms |
| 10 MB | 939 ms | 942 ms | 597 ms |
| 25 MB | 2.3 s | 2.3 s | 1.5 s |
You can try it yourself: open the Large JSON Viewer, press Load Sample, then Large (about 25 MB).
What was measured
- Shown as valid: from handing the file to the app (the same path as the Open button) until the status bar shows Valid JSON with the size, depth and node count. It includes reading the file, loading it into the editor and parsing it.
- First tree rows: until the first rows of the tree view are on screen.
- Longest main-thread pause: the longest long task (over 50 ms) the browser reported on the page's main thread, using the Long Tasks API. While a long task runs the page cannot react to clicks or scrolling.
The test files are generated records (ids, names, emails, nested address objects, short tag arrays and some nulls), pretty-printed, about 40 nodes per record. A 25 MB file contains roughly one million JSON nodes. Real files differ, and deeply nested or string-heavy documents can behave differently.
How it stays responsive
- Parsing in a Web Worker. The text is parsed, measured and formatted off the main thread. The parsed value stays inside the worker.
- A virtualized tree. The worker flattens only the visible part of the tree into rows, and the page draws just the rows that fit on screen, a few dozen DOM nodes, however large the document is. Expanding, collapsing and searching ask the worker for a new list of rows.
- The editor owns the text. The document is not kept in React state, so typing does not copy megabytes on every keystroke.
- Caps and lighter modes. The tree lists at most 250,000 rows at once, and above a few megabytes the editor drops its minimap and language services.
What still pauses the page
Honest limits: loading the text into the Monaco editor runs on the main thread. In these runs that cost about 60 ms per megabyte, which is why the longest pause is about 1.5 seconds at 25 MB. Parsing itself does not block the page, but reading and displaying the text does. We have not tried to hide this: for very large files a future version could skip the editor and show a read-only view while the worker does the work.
We also have not measured other browsers, phones, or other JSON tools, so this page makes no comparison claims. If you run the script on your own hardware, we would like to see the numbers.
Reproduce it
git clone https://github.com/megezgen/jsonforge.git
cd jsonforge
npm install
npm run build
node scripts/benchmark.mjs # serves ./out and measures 1, 5, 10 and 25 MB
SIZES=50 RUNS=5 node scripts/benchmark.mjsThe script needs Google Chrome installed and prints your hardware next to the results. Set BASE_URL to measure a deployed site instead.
Tips for working with very large JSON
- Collapse everything first and expand only the branch you need; search narrows the tree to the paths that match.
- Use the JSONPath tester to pull out just the values you care about instead of scrolling.
- For files above 100 MB, a command-line tool such as jq is a better fit than any browser.