Why we built a JSON viewer in 2026.
Every editor has a JSON mode. None of them open the file we needed to look at. So we wrote one — for the file your editor refused.
The 4.8 GB file
It was a Tuesday. A customer's checkout flow had been silently broken for nine hours, and the only artifact that survived was an event log: events_2026-03-04.json, 4.8 GB, one big array.
Two of us tried to open it. VS Code spun for 90 seconds and gave up. Firefox's built-in viewer lasted longer — 4 minutes — before the tab crashed. jq '.[0]' took 38 seconds to print one record. By the time we'd head -n 5000'd a manageable slice into a smaller file, we'd lost the thread of why we were looking in the first place.
We did fix the bug. But we walked out of the incident annoyed at the wrong thing: not the bug, the tools.
The market is full of JSON viewers
We checked. There are at least 30 of them. They fall into three buckets:
- Editor extensions. Great up to a few megabytes. Then they freeze the editor.
- Web tools. Beautiful for sharing tiny payloads. Useless past 50 MB and you wouldn't paste production data into one anyway.
- CLI parsers. Fast at one thing — extracting — but you can't look at a file with them. You can only ask narrow questions and hope.
None of them treat the file as something you'd want to wander around in. None of them admit that "1 GB" is a normal size for a JSON file in production in 2026.
What we wanted
We sat down and wrote a wishlist before writing any code. Three rules:
- Open at the speed of the disk. If your SSD does 3 GB/s, the viewer should not be the bottleneck. Anything slower is the tool wasting your time.
- Explore without a query language first. JSONPath is fine. But step one is "let me see what's in there." Tree first, query second.
- Don't load the file into RAM. A 32 GB laptop should open a 120 GB file. Map, don't load.
The rules became the architecture
Each rule pinned down a piece of the engine:
Rule 1 forced SIMD parsing and a branchless tape — every byte gets one prediction-friendly path. We'll go deep on that in another post.
Rule 2 forced a virtualized tree. Render the rows on screen; index everything else. A 200-million-node file scrolls smooth because we never build a 200-million-node DOM. We build six.
Rule 3 forced memory-mapped indices. Parse once on first open, write a sidecar index file. Every subsequent open is a constant-time mmap, regardless of file size. Open a 50 GB file twice, and the second open is 8 ms.
Six months later
The first internal build opened a 1 GB file in 4 seconds. We were thrilled. Six iterations later, that's 510 ms. The current public build moves at 2 GB/s sustained parse on an M2 Pro, and search happens against the index, not the file — so the first match for a needle in a 50 GB haystack lands in around 60 ms.
Numbers are easy to brag about. The thing we actually built it for is the moment we stopped mentioning. You don't notice it opening anymore. You drop the file, you look at it. The file is the subject again. The tool is invisible.
It costs nothing to use
jsonbolt is free for individuals. We charge teams for collaboration features (shared workspaces, audit trails, SSO). The viewer itself stays free, forever. We're not playing the "free for the first 5 MB" game — that's exactly what we built jsonbolt to escape.
Download it. Open the biggest JSON file you have. Tell us if it surprises you.