It exists.
In my last experiment, I asked four AIs how to investigate a 50 GB log, and Copilot recommended a tool I had never heard of: Log Voyager. I looked it up — not only does it exist, it has a real reputation: "analyze huge log files instantly in your browser," "opens 100 GB."
Well. There was only one thing to do: measure it.
The matchup — same arena: the browser
My own viewer, UwView, happens to have a WebAssembly build — a free, browser-based version I publish for technical validation. Which means a genuinely fair fight is possible: browser vs browser.
- Target: OpenStreetMap Japan XML — 47.73 GB / 892,239,125 lines, single file
- Search term:
東京("Tokyo") - Environment: MacBook Air (M4, 32 GB RAM, macOS 26.3.1); data on an external USB SSD; same Chrome for both
- Full disclosure up front: one contender is my own tool. Discount accordingly
(Screenshots are in the original article on my blog — side-by-side windows of both viewers on the same file.)
Results
| Loading | Searching "東京" | |
|---|---|---|
| Log Voyager (Web) | △ displays 47.73 GB loaded, but the last visible line breaks off mid-file (~5 GB actually read, estimated from line numbers) | never ran — 0 results (multiple attempts) |
| UwView Wasm build (Web, free) | ✔ | completed: 94,979 hits |
| UwView Pro desktop (reference) | ✔ | 94,979 hits + drill-down refinement |
Log Voyager displays the full 47.73 GB as loaded — but the last visible line breaks off mid-file; from the line numbers, only about 5 GB appears to be actually readable. And the search never moved at all — 0 results, every attempt (all from my environment). Same file, same term, in my Wasm build: finished, 94,979 hits, same browser.
I then went hunting for the floor: 10 million lines (980 MB), then 1 million lines (98 MB). Even at 98 MB the search never completed on my machine (stuck at 99%, 0 results).
Could it just be a no-match? Ruled out, two ways: the exact ID Log Voyager was searching for exists at line 881,107 of that file (the Wasm build pins it instantly), and Log Voyager itself was displaying content past that point (~line 993,083, also verified). It displays the data, yet a search for a string that provably exists returns nothing — the search simply is not functioning. I stopped digging there.
Why the gap (partly informed guesswork)
Log Voyager is built on JavaScript + IndexedDB, which means it takes the browser's memory ceiling and garbage collector head-on. Fine at a few GB; painful at ~50 GB. That's my outside reading — I have not audited its internals, so treat this paragraph as a hypothesis.
Why my Wasm build survives is something I can explain: it manages its own heap inside WebAssembly and reads in chunks, sidestepping GC entirely. "Runs in the browser" describes two very different ceilings, depending on whether you're standing on JS or on Wasm.
In fairness: this result may not represent what Log Voyager can actually do. It did not work well in my environment — and that could be a configuration or usage problem on my side. If you have compared Log Voyager and the UwView Wasm build on a ~50 GB file, please let me know in the comments: I will update this article to match the evidence. Its author publishes the code on GitHub and takes Ko-fi support, and the zero-install design philosophy is admirable — fellow indie developer to fellow indie developer.
The browser build is the entrance, not the building
Here's the honest twist: the winner of this match — my own Wasm build — is not even part of my product line. It's a technical-validation reference build.
- UwView Wasm (free, browser) — today's winner, still under the browser's ceiling; the lowest-performing reference build
- UwView desktop (free) — native mmap, faster than any browser build; still a reference
- UwView Pro — persistent sidecar cache (0.02–0.07 s reopen on my machine; varies by hardware) and drill-down search; the products built for real work start here
- UwView Pro + Edit Upgrade — adds non-destructive editing of huge files; the top configuration
"Opens 100 GB in your browser" is a stirring banner, but the browser has a structural ceiling — mine included. If huge files are your daily work, you end up in a native app. This experiment just made that ladder visible, my own products included.
Full disclosure
- One file, one machine. Log Voyager's truncated load and non-starting search are what I observed in my environment; yours may differ ("~5 GB actually read" is an estimate from the last visible line number)
- The "why it stalls" section is inference, not audit
- My Wasm build is a technical validation artifact, not a supported product
- I measured completion and hit counts, not elapsed times
Try both yourself — each is just a URL:
- Log Voyager: https://www.logvoyager.cc/
- UwView Wasm build: https://amru195704.github.io/UwView/
UwView Pro is on sale (Windows, macOS, Linux — one license covers all three; 14-day free trial — editing features included). Screenshots and the full ladder are in the original article:
https://uvp.y42u.net/en/blog/uwview-logvoyager-wasm-comparison-en/
Top comments (0)