Known Limitations

Giant JSON Viewer is built to handle files that crash other apps. It uses memory mapping, native code, and a structural index to navigate multi-gigabyte JSON files on mobile devices with constant memory usage.

But every system has boundaries. This article explains what those boundaries are, when you might encounter them, and what to do if a limitation affects your workflow.

Architectural Limits

The app's index format (v3) defines several hard limits that ensure stability on mobile devices:

Limit	Value	What it means
Maximum file size	1 TB	Files larger than 1 terabyte cannot be indexed. The internal offset format uses 40 bits, which caps at 1 TB.
Maximum nesting depth	255 levels	JSON structures nested more than 255 levels deep will trigger an early exit. This prevents stack overflow during parsing.
Maximum node count	~4.3 billion	The index uses 32-bit node addressing. Files with more than 4.3 billion objects and arrays cannot be fully indexed.
Maximum children per container	~4.3 billion	Any single object or array can contain up to 4.3 billion items.

Will you hit these limits?

Almost certainly not. A 1 TB JSON file would be exceptional even in enterprise data processing. Nesting depth of 255 is far beyond any practical data structure (most APIs nest 3-10 levels deep). And 4.3 billion nodes would require an extraordinarily large file.

These limits exist as guardrails for system stability, not as practical constraints.

Structure Mode: Sampling Behavior

When you view a file in Structure Mode (the tree view), the app analyzes the JSON to show you a collapsible schema. For performance on huge files, this analysis uses smart sampling rather than exhaustive scanning.

How it works

1. Arrays: The engine samples up to 100 items from each array to determine the element type pattern. It uses majority voting: if 95 of 100 sampled items are objects with similar keys, the structure view shows that pattern.
2. Objects: All keys are displayed, but type inference samples the values. If a key sometimes contains a string and sometimes a number, the type shown is the majority type from the sample.
3. Depth limits: The structure tree analyzes up to 30 levels deep and displays up to 500 children per level, with a global cap of 10,000 nodes in the tree.

What this means for you

If your array contains 1 million items where the first 100 are objects but items 101+ are strings, the Structure Mode will show the array as containing objects (since that was 100% of the sample).

For precise type checking across all items, consider using export filtering or search to validate specific patterns.

Long Lines and Large Values

Android's text rendering system can struggle with extremely long lines. To prevent freezes, both viewing modes apply truncation:

• Text Mode detects lines longer than 10 KB and shows a warning before rendering
• Browser Mode also truncates value previews to 5 KB with an indicator showing the original size

What about the actual data?

Since version 1.6.0, Browser Mode includes Encoded Data Detection. When a value contains base64-encoded content matching one of 50+ known file formats (images, documents, archives, etc.), the app displays a special indicator and allows you to extract and download the original file.

This means even if a 10 MB embedded image is truncated in the preview, you can still save it to your device.

If you work primarily with minified JSON (single-line files) or base64-encoded data, Browser Mode with Encoded Data Detection enabled is the recommended approach.

Index Storage

The structural index is stored in your device's app cache directory, and keeping large files in your Recent Files list means keeping their indexes.

How much storage does indexing use?

Each indexed node (object or array) costs exactly 32 bytes of storage. Primitive values (strings, numbers, booleans) are not indexed.

File description	Indexed nodes	Index size
Simple API response (50 objects)	50	~1.6 KB
Medium dataset (10,000 arrays/objects)	10,000	~320 KB
Large export (1 million containers)	1,000,000	~32 MB
Massive log file (100 million nodes)	100,000,000	~3.2 GB

Additional auxiliary files (sparse line index, line length cache, keys index) add modest overhead, typically 1-5% of the structural index size.

Storage implications

• Re-indexing is required after clearing the app cache
• Index files are stored separately from your original JSON files
• Remote files (fetched via URL) are stored in app data and lost if the app is uninstalled
• Removing a file from Recent Files deletes its associated indexes

You can view your total storage usage and per-file breakdown from the Recent Files screen.

What Giant JSON Viewer Doesn't Do

To set expectations clearly:

• No editing: This is a viewer only. You cannot modify files within the app.
• No XML, YAML, or TOML: Only JSON, NDJSON, and plain text are supported.
• No cloud sync: Files and indexes stay on your device.

Hitting a Limitation?

If any of these boundaries blocks your actual use case, we want to hear about it. Understanding real-world edge cases helps us prioritize improvements.

Open an issue on GitHub: github.com/kotysoft/GiantJSON/issues

When reporting, please include:

• A description of your file (approximate size, structure type)
• Which limitation you encountered
• What you were trying to accomplish

All feedback helps shape future development.

Summary

Area	Limit
File size	1 TB
Nesting depth	255 levels
Indexed nodes	4.3 billion
Structure Mode sampling (arrays)	100 items
Structure tree depth	30 levels
Structure tree children per level	500
Long line threshold	10 KB

For typical JSON files, including multi-gigabyte ones, these limits are invisible. The app is designed so you only think about limits when you genuinely need to.