OmniJSON / Guide
Large JSON performance and practical limits
Documentation checked against 0.1.14. Version notes and publisher support; check the store listing for availability.
Updated
A large JSON file’s size alone does not predict how long it takes to open. Node count, string lengths, source speed and available memory all matter. OmniJSON parses locally and lets you browse progressively, but it does not promise a fixed loading time or frame rate on every device.
Why is a large JSON file slow to open?
Opening a web URL includes requesting and receiving the source, parsing it, and preparing the viewer. A slow server or connection can delay completion even when local parsing is fast. Worker parse time and total loading time describe different parts of that work; compare them only when the measurement scope is the same.
While data arrives, browse available rows and use Search or Fields. A partial tree is not a complete document. Wait for parsing to finish before running JSONPath or judging whether a field is missing. To stop work, use Cancel; it aborts active input and parsing so a subsequent document can start cleanly.
Why can two similarly sized files behave differently?
A file containing many small objects creates more nodes than one containing a few long strings. Deep nesting, unique keys and long values also change the work and memory required. A dense file can therefore take longer than a text-heavy file of the same byte size.
From roughly 50 MB or 500,000 nodes, OmniJSON uses large-document mode. The viewer requests visible rows on demand; its initial view may be shallow. Expand a branch or adjust the depth control to explore further. This reduces how much tree data reaches the interface, but the underlying document and indexes still require memory.
Choose an operation that fits the document
- Find a word or key: use Search for case-insensitive substring matching over keys and scalar values.
- Keep known fields: use Fields with exact key names, such as
id, status. - Follow a structural path: after parsing, use JSONPath Lite on large documents. Predicates, slices, unions, comparisons and functions are unavailable in Lite.
- Copy a scalar: Copy value accepts up to 4 MiB of decoded UTF-8 text; JSON escaping can increase the resulting literal size.
- Copy a subtree: the limit is 1 MiB and 10,000 nodes. Oversized requests return an error rather than silently copying a partial result.
Regular mode supports full JSONPath within query budgets. Query-time memory is different from steady-state storage. Browser process memory, WASM memory and internal buffer measurements overlap and must not be added together as independent totals. There is no universal browser-memory ceiling promised for every document.
OmniJSON reads one JSON object or array per document. JSONL/NDJSON, editing and saving are outside its current scope. See the worked query examples before choosing a filter.
What evidence supports the large-document design?
A historical local validation run on October 4, 2026 passed the recorded correctness and regression gates. It used an Intel Core m3-7Y32 machine with 8 GiB RAM, macOS on x64 and Chrome 154.0.8037.97. The suite included text-heavy and dense synthetic documents, repeated filtering and lifecycle checks.
The recorded frame-rate optimization target was not met. Power, thermal state and other desktop load were not locked. These results describe that historical build, not a benchmark of 0.1.14, a guarantee for arbitrary inputs, or a claim about every user’s device.
Download the validation provenance summary for the build identifier, source-document hashes and scope. This is a summary of archived evidence, not the complete raw measurement report. Demo screenshots are illustrations of individual runs, not throughput benchmarks.
For a useful problem report, record the installed version, Chrome version, approximate file size, whether the source is local or remote, and whether it contains many small objects or large strings. Start with a non-sensitive sample. Follow the recovery guide if opening fails.