Real question, does it manage nested objects ?

You know what would really be useful is a conformance test based on a particular real implementation.

What I mean by this is a subset (superset?) that exactly matches the parsing behavior of a specific target parsing library. Why is this useful? To avoid the class of vulnerabilities that rely on the same JSON being handled differently by two different parsers (you can exploit this to get around an authorization layer, for example).

It doesn't seem to have much in the way of validation, e.g., it will indiscriminately let you use either ] or } to terminate an object or array. Also, it's more lenient than RFC or json.org JSON in allowing '\v' for whitespace. I'd treat it more as a "data extractor for known-correct JSON". But even then, rolling your own string or number parser could get annoying, unless the producer agrees on a subset of JSON syntax.

> Zero-allocations with minimal state

Probably this part from the README. For example, you may want something like this when running a service on a device with limited memory.

Small code is easier to review, so projects with strict security requirements might be one?

Also, license compliance is very easy (no notice required).

I suppose it's meant as a minimal library meant to be modded for the specific usecase.

Embedded cpus is an easy one. You could maybe run an api server on a vape now.

Trivial to integrate into an existing code base, minimal size overhead, no heap allocations, no stdlib usage (only stdbool.h and stddef.h included for type definitions), no C++ template shenanigans and very simple and straightforward API. C libraries which tick all those boxes are actually quite rare, and C++ libraries are much rarer.

A small single file, pure C dependency that doesn't allocate memory can be a universal solution to a common problem if it works well.

Being able to parse without a lot of overhead and without allocations is quite interesting. E.g. when you process some massive json dump to just extract some properties (the Wikidata dumps come to mind).

the more the merrier

You can't get much more 'opinion-less' than this library though. Iterate over keys and array items, identify the value type and return string-slices.

The project advertises that it has zero-allocations with minimal state. I don’t think it is fair or our problems are very different. Single string, (the most used type), and you need an allocation.

It's astonishing how involved a fucking modern JSON library becomes.

The very simple C++ single-header JSON library by nlohmann is now * 13 years old * is still actively merging PRs * has 122 __million__ unit tests

Is self-admittedly still not the fastest possible way to parse JSON in C++

That's detected as an error though?

https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1...

Submit a PR!

There was a nice article [0] about bloated edge cases libraries (discussion [1]).

Sometimes, it's just not the responsibility of the library. Trying to handle every possible errors is a quick way to complexity.

[0]: https://43081j.com/2025/09/bloat-of-edge-case-libraries

[1]: https://news.ycombinator.com/item?id=45319399

An int will be 32 bits on any non-ancient platform, so this means:

- a JSON file with nested values exceeding 2 billion depth

- a file with more than 2 billion lines

- a line with more than 2 billion characters