json/docs/mkdocs/docs/features/parsing/large_and_partial_input.md

Large, Streamed, and Partial Input

parse reads exactly one complete JSON value and builds it in memory. It cannot be paused and resumed, and it does not hand back a half-parsed value when the input ends early. This page shows what to do when the input does not fit that model: it arrives in pieces, it contains several values, or it is too large to hold as a json value.

flowchart TD
    A["my input is..."] --> B{"several JSON values in one stream?"}
    B -->|"yes"| C["read them one at a time"]
    A --> D{"arriving in chunks (socket, pipe)?"}
    D -->|"yes"| E["frame the messages, or buffer until complete"]
    A --> F{"too large to keep in memory?"}
    F -->|"yes"| G["discard parts with a callback, or use SAX"]
    A --> H{"only a small part is needed?"}
    H -->|"yes"| I["stop early with SAX, or read through a view"]

Questions about the input and the approach this page describes for each; an input can match more than one question.

Several values in one stream

For newline-delimited input, read line by line and parse each line, as described in JSON Lines. For values that are simply concatenated, operator>> reads one value and leaves the stream positioned after it. Check for the end of the stream before each read, because a read at the end throws:

??? example "Example: read concatenated values"

```cpp
--8<-- "examples/partial_input_concatenated.cpp"
```

Output:

```
--8<-- "examples/partial_input_concatenated.output"
```

The same works for binary formats. from_cbor and its relatives accept #!cpp strict = false to stop after the first value and leave the rest of the stream untouched; tellg() then reports how many bytes the value took:

??? example "Example: read one CBOR value and find out how many bytes it used"

```cpp
--8<-- "examples/partial_input_cbor.cpp"
```

Output:

```
--8<-- "examples/partial_input_cbor.output"
```

Input arriving in chunks

A socket, pipe, or HTTP body hands over data in pieces of arbitrary size, and a piece can end in the middle of a number, a string, or an object. The parser does not keep state between calls, so there are two ways to deal with this.

Frame the messages. The most robust approach is a protocol that says where a value ends: one value per line (JSON Lines), a length prefix, or a delimiter. Collect the bytes of one message and parse them when the frame is complete. Prefer this whenever you control the protocol.

Buffer until the value is complete. If the data has no framing, append every chunk to a buffer and try to parse it. A parse error at the very end of the buffer means that the input ended prematurely, while an error anywhere else is a real syntax error. The member byte of the parse_error exception is one past the buffer size in the first case:

??? example "Example: buffer chunks until the value is complete"

```cpp
--8<-- "examples/partial_input_buffering.cpp"
```

Output:

```
--8<-- "examples/partial_input_buffering.output"
```

The example feeds a document in five chunks. The first four are reported as incomplete, and a syntax error is reported as such, not as missing data.

The chunks of the example, and the bytes each attempt parses again:

--8<-- "images/chunk_buffering.svg"

Each row is one parse attempt on the growing buffer: an error at the byte after the end of the buffer means the value is incomplete, an error before the end is a real syntax error. The last line adds up the bytes parsed over all attempts.

!!! warning "Limits of buffering"

- The buffer must contain exactly one value. Data that belongs to the next value is a syntax error. Use framing if
  values follow each other without a separator.
- A number at the end of the buffer is a complete value, even if more digits are still to come (`12` may be the
  start of `123`). Buffering cannot detect this; use framing for top-level numbers.
- Every attempt parses the buffer from the beginning, so the total work grows quadratically with the size of the
  value. Limit the size of the buffer for input you do not trust (see [untrusted input](untrusted_input.md)).

Input too large for memory

The input does not have to become one huge json value. The two tools below process it piece by piece.

How the memory use develops while a large array of records is parsed (illustrative, not a measurement):

--8<-- "images/memory_over_time.svg"

Memory use over the number of records parsed: `parse()` keeps the whole tree, `json_document` the text plus its index, a discarding callback one record at a time, and SAX only what the handler keeps.

Handle and discard elements with a callback

A parser callback is called for every finished value. If it returns #!cpp false, the value is discarded and its memory is released at once. For a file that consists of one huge array (or one huge object) of records, handle each record at depth 1 and discard it:

??? example "Example: handle and discard each record of a large array"

```cpp
--8<-- "examples/partial_input_discard_records.cpp"
```

Output:

```
--8<-- "examples/partial_input_discard_records.output"
```

Only one record is in memory at any time. The same recipe, with more detail, is in the parser callbacks page. To skip entire members you do not need, discard them when their key is read; see the example for parse_event_t::key.

Extract a few values and stop with SAX

With the SAX interface, no value is built at all, and returning #!cpp false from any handler function stops the parser. sax_parse then returns #!cpp false, and the rest of the input is not read. The example finds the first id in a document without parsing the remainder:

??? example "Example: stop parsing as soon as a value is found"

```cpp
--8<-- "examples/partial_input_sax_stop.cpp"
```

Output:

```
--8<-- "examples/partial_input_sax_stop.output"
```

Note that sax_parse returns #!cpp false both when a handler stopped the parse and when the input is invalid, so record the reason in the handler (here: id) if you need to tell the two apart.

Read parts of a large document with a view

If the whole text is available and you only need to read some of it, a json_document from <nlohmann/json_view.hpp> (added in version 3.13.0) avoids the basic_json tree altogether: it keeps the text, builds a flat index of the values, and gives read-only views of the parts you look at. Only what you materialize() becomes a basic_json value. See Zero-copy JSON views for details and for the lifetime rules.

See also

• Parsing - overview of the parsing functions
• JSON Lines - newline-delimited JSON
• Parser callbacks - discard values while parsing
• SAX interface - event-based parsing
• Zero-copy JSON views - read parts of a large document without building a tree
• Untrusted input - limits for input you do not control