The fastest JSON viewer and parser on the web

A claim is only worth as much as the run behind it. So here are the runs: cold-start medians from a 294-byte package.json to a 19.62 GB real-world document, on two Apple-silicon Macs, measured against production with a script anyone can download and re-run.

benchmark performance throughput mb/s large json

What “fastest” means here

Most JSON tools online quietly cap out in the low megabytes: paste a 50 MB file and the tab spins, paste a gigabyte and it dies. Fast JSON Viewer is built the other way around. It streams the file through a pool of Web Workers in 256 KB blocks, validates and indexes the bytes without ever building a live object tree, and renders through a virtual scroller. Nothing is uploaded; everything runs in your browser. That design is what lets a 9.9 GB file open at all, and it is what this benchmark measures.

Two numbers matter, and they are different jobs:

• First page — milliseconds from dropping the file to the first painted page of formatted, scrollable JSON. This is the number you feel. It stays under 200 ms at every size, because the viewer paints the top of the file as soon as the first block is ready and indexes the rest in the background.
• Parse — milliseconds to validate and index every byte in the file. Divide the file size by this and you get throughput in MB/s, the headline number for a parser. It is the work that actually scales with file size, so it is the work worth making fast.

This is not a comparison against JSON.parse. That builds a full in-memory object, a different and much heavier job we deliberately never do. Our throughput is the cost of validating the bytes and recording the metadata the viewer needs to scroll and collapse them — see the WASM vs JavaScript write-up for what that pass does and why it ships in both JS and SIMD form.

MacBook Pro M5 (Mac16,5), 64 GB memory

Every row below is the median of 21 cold runs — a fresh browser with nothing cached on each iteration — against fastjsonviewer.com in headless Chromium 149. The table is sorted by file size, largest first. Throughput is file bytes ÷ parse time.

↳ Open the raw benchmark-results.json in the viewer ↗ — every sample, variance and the exact browser build, loaded into Fast JSON Viewer itself through a #jsonString= share link.

Read the throughput column top to bottom and the shape of the engine shows up: the bigger the file, the faster it goes, peaking at 1,089 MB/s on the 19.62 GB real-world file while still painting its first page in 45 ms. The small files look slow in MB/s for a boring reason — a 294-byte file finishes in 15 ms, but most of that is a fixed floor of worker spin-up and browser navigation that no amount of parser speed can shave. Throughput only becomes a meaningful number once the file is large enough to amortize that floor, which is exactly the regime this viewer is built for.

Parse throughput vs file size

Plotting throughput against size (log scale on the x-axis, one tick per decade from 0.1 MB to 10,000 MB) makes the climb obvious: the per-byte loop keeps getting more efficient as the fixed costs fade into the background.

Throughput in MB/s (file bytes ÷ median parse time), plotted at the 0.1 MB, 1 MB, 10 MB, 100 MB, 1000 MB and 10,000 MB points. The 100 MB and 1 GB points sit nearly on top of each other at ~464 MB/s; the curve keeps climbing from there, and the 19.62 GB real-world file (a row in the table, off the right edge of this decade axis) is the fastest of all.

MacBook Air M2 (Mac14,2), 16 GB memory

Every row below is the median of 21 cold runs — a fresh browser with nothing cached on each iteration — against fastjsonviewer.com in headless Chromium 149. The table is sorted by file size, largest first. Throughput is file bytes ÷ parse time.

↳ Open the raw benchmark-results.json in the viewer ↗ — every sample, variance and the exact browser build, loaded into Fast JSON Viewer itself through a #jsonString= share link.

Read the throughput column top to bottom and the shape of the engine shows up: the bigger the file, the faster it goes, topping out at 421 MB/s on the 9.9 GB file while still painting its first page in 77 ms. The small files look slow in MB/s for a boring reason — a 294-byte file finishes in 17 ms, but most of that is a fixed floor of worker spin-up and browser navigation that no amount of parser speed can shave. Throughput only becomes a meaningful number once the file is large enough to amortize that floor, which is exactly the regime this viewer is built for.

Parse throughput vs file size

Plotting throughput against size (log scale on the x-axis, one tick per decade from 0.1 MB to 10,000 MB) makes the climb obvious: the per-byte loop keeps getting more efficient as the fixed costs fade into the background.

Throughput in MB/s (file bytes ÷ median parse time), plotted at the 0.1 MB, 1 MB, 10 MB, 100 MB, 1000 MB and 10,000 MB points. The small dip at 100 MB is real run-to-run variance, not a wall — the trend resumes and the 10 GB file is the fastest of all.

Methodology

The whole point of publishing this is that you don't have to take the numbers on faith. The benchmark is a single standalone script — download it from the /bench page — that drives a real browser against any deployment with your own files:

1. It launches a cold browser for every run: a fresh context with an empty cache, so no run benefits from a warmed-up JIT or a cached asset. The table above used 21 runs per file.
2. For each run it opens the page, drops the file in, and records two timestamps from the app itself: first page (first formatted paint) and parse (validate-and-index complete).
3. It reports the median of those runs — not the best, not the mean — along with variance, standard deviation and the full raw sample list, plus the exact browser build and platform. All of that is in the benchmark-results.json linked under the table.
4. Files are matched by size, not name, so you can point it at your own data. Generate test files of any size with the built-in JSON document generator.

# reproduce this run against production
curl -O https://fastjsonviewer.com/benchmark.mjs
npm init -y && npm install playwright && npx playwright install chromium
node benchmark.mjs --runs 21 100kb.json 1mb.json 10mb.json 100mb.json 1gb.json 10gb.json

The runs on this page were Chromium 149.0.7827.55, headless, Node v26, on a MacBook Pro M5 (Mac16,5, Darwin arm64) with 64 GB of memory and a MacBook Air M2 (Mac14,2, Darwin arm64) with 16 GB. Full reproduction instructions and every flag live on the benchmark page.

Why the curve goes up, not down

Most parsers get slower per byte as files grow, because they are building a structure that has to live in memory. This one gets faster, because it never builds that structure. Each 256 KB block is validated and indexed independently across the worker pool, the SIMD byte loop hits its stride once it has long runs to chew through, and the fixed costs — spinning up workers, navigating the page, painting the first screen — are paid once and then drowned out. A 294-byte file is almost entirely fixed cost. A 9.9 GB file is almost entirely the hot loop, and the hot loop is the part we optimized. That is why the honest headline is not a single number but a direction: the bigger your JSON, the further ahead this viewer pulls.

⊹ Open the viewer Run the benchmark Generate a test file How the parser works