Formatter Validator Minifier Escape / Unescape JSON ↔ String JSON ↔ YAML JSON → CSV NDJSON / JSON Lines JSON → Types JSON ↔ XML JSON Diff JSON Patch Canonicalize (RFC 8785) Schema Validator Schema Generator JSONPath Tester JWT Decoder JSON Errors Schemas More Tools
JSONTools / Blog / Measured
Measured

Streaming a 101 MB JSON file uses 1 MB of memory

JSON.parse on a 101 MB document costs 2.9 seconds and 299 MB of heap before you can do anything with it. A streaming byte scanner does the same validation in 620 ms and 1 MB. Here are the numbers.

Same file, two approaches

StepTimeHeap
Read bytes102 ms0 MB
Bytes → JavaScript string598 ms104 MB
JSON.parse2,296 ms299 MB
Streaming scanner (validate)620 ms1 MB

A 101 MB file of flat records. Deeply nested data with many small objects typically costs 5–8× the text size as an object graph, not 3×.

Most operations do not need the values

The object graph is the expensive part, and validating, minifying and formatting do not need it. A byte-level scanner tracks a container stack and nothing else, so its memory is proportional to nesting depth rather than document size.

Operations that genuinely need parsed values — JSONPath, schema validation, diffing — cannot avoid the object graph and cap far lower. That distinction is worth being honest about rather than advertising a single number.

Where the difference becomes obvious

A trailing comma was injected 85% of the way into the same 101 MB file:

ApproachTimeMemoryResult
JSON.parse2,174 ms+139 MBa message and a text snippet, no position
Streaming scanner412 ms0 MBexact byte offset → line and column, stopped reading at 86 MB

Anything built on JSON.parse must load the entire document before it can say anything at all. Past roughly 500 MB it cannot answer, because it runs out of memory before reaching the error.

On your own machine

Our formatter streams any file over 4 MB, up to 100 MB, entirely in your browser. Generate a test file of any size with the test file generator — including deliberately broken ones so you can see where the error is reported.

Standards referenced

RFC 8259 §9 permits an implementation to limit text size, nesting depth, number range and string length — the basis for the honest per-tool caps.

Peer-reviewed literature

Only standards bodies and peer-reviewed venues are cited here.

How this was measured

Node.js 22 on Linux, heap measured with --expose-gc between runs. The scanner reads the file in 1 MB chunks and never materialises the document as a string or an object.

Every figure on this page came from executing the parser named, not from documentation. The collection harness is public — see the error registry method notes.

More on this