The project claims 4x speed by changing how you read JSON
simdjson's README says it parses more than 4 times faster than common production parsers, with higher figures for individual jobs such as UTF-8 validation. We did not reproduce those benchmarks. The useful design fact is that the default On-Demand API avoids building a complete tree. A document is an iterator over the original text, so the parser can skip values that the application never asks for. Less work is the source of much of the appeal.
That bargain changes application code. The parser instance, input string, and document must stay alive during parsing, and one parser can have only one open document. Returned string_view values can point into the source or a temporary parser buffer. Parsing another document can invalidate them. The basics guide explains these rules clearly, but a team used to retained DOM values still has to design around them.
One header and one source file cover the basic C++ path
A release includes simdjson.h and simdjson.cpp, which can be copied into a C++ project and compiled with the application. The documented floor is GCC 7.4, Clang 6, Xcode 11, or Visual Studio 2017, depending on platform. CMake, package-manager, submodule, and FetchContent routes are also documented. Runtime CPU detection selects an implementation, so the maintainers advise against architecture-specific compiler flags when one binary must run across several machines.
Input handling is the part to review before adoption. On-Demand always needs padded input, though C++17's padded_input can manage that automatically. A user-owned buffer needs extra SIMDJSON_PADDING bytes. The DOM API has a separate unpadded route. Development checks can catch incorrect iteration patterns, while release builds should define NDEBUG to avoid their cost. These are workable rules, but they belong in code review and tests, not tribal memory.
What happened when we ran it
Our run at commit 23b236d used the Rust project under benchmark/static_reflect/serde-benchmark/, inside an unprivileged container with 3 CPUs and 12 GB of RAM. Installation completed in 1 second and added 15 packages. The build succeeded in 7 seconds. The repository checkout contained 773 files, about 119,390 source lines, and occupied 34.2 MB before those packages. Our scan found 44 CI workflow files and a tests directory.
cargo test exited successfully after 1 second, reporting 0 passed and 0 failed out of 0 tests. That is an empty test run, not evidence that the core C++ parser passed its suite. Our test method followed the detected nested Rust target, so it also did not compile the single-header C++ path, exercise runtime CPU selection, validate padded-buffer behavior, or measure JSON throughput. The honest result is that one ancillary benchmark crate built cleanly.
Version 4.6.11 fixed six parser defects
The latest release, v4.6.11, was published on September 5, 2026 and lists 6 fixes from an audit. They include silent truncation of a root scalar at a parse_many window boundary, an out-of-bounds write when maximum depth was zero, and a source-view length underflow across batches. The release also corrected a UTF-8 window-edge case, 32-bit capacity guards, and allocation-failure state. Those are strong reasons to pin a current release.
The maintainers say the development branch may contain extra bugs and tell production users to work from releases with matching documentation. Follow that advice. A parser sits on an untrusted-data boundary in many systems, and v4.6.11 shows that obscure window and allocation cases matter even in a mature project. Build regression inputs from your traffic, fuzz the options you enable, and review release notes before upgrading or holding back.
JSONPath and compressed input still have hard limits
The documented at_path() method supports the subset of JSONPath that can be converted to JSON Pointer. Full JSONPath remains requested in issue 2070. The current path call can rewind the parser and invalidate previously read values, so callers must consume results between calls. That is quite different from keeping a tree and issuing arbitrary queries against it. Choose the API because the access pattern fits, not because the library tops a chart.
Compressed input is another boundary. Issue 1020 says applications currently decompress a JSON document before parsing it. The performance guide also notes that densely packed floating-point numbers can become the limiting work. Benchmark decompression, allocation, parsing, and value extraction together on the CPUs you deploy. simdjson is the right candidate when that full measurement shows a win and the 64-bit C++ integration rules remain acceptable.
September activity makes comparison cheap
GitHub recorded a push on September 25, 2026. The repository had 24,272 stars, 73 combined issues and pull requests, and 56 open issues when fetched. The same month brought v4.6.11 and its 6 audit fixes. That combination shows active maintenance and active scrutiny. The dual Apache-2.0 or MIT choice also removes most licensing friction for a technical trial.
Try simdjson beside yyjson, RapidJSON, and JSON for Modern C++ using representative payloads and the queries your application actually makes. Keep correctness checks identical, include allocation and decompression costs, and record the CPU model. If the profiler cannot show a meaningful end-to-end gain, the easier object model is the better engineering choice. If it can, On-Demand's lifetime rules are a fair price for measured savings.