simdjson picks your parser at runtime and hands the rest to your toolchain

The parser is chosen by the CPU at startup, so one binary runs different code paths

The project summarizes its dispatch in one line: it selects a CPU-tailored parser at runtime, with no configuration needed. The file that covers runtime CPU detection and how you can work with it is doc/implementation-selection.md, and the five quick start steps never touch the topic. That means the parser you run is a property of the machine, not of your build. A binary compiled once and shipped to mixed hardware selects whatever implementation the target CPU supports, and nothing in the quick start tells you how to inspect that choice or hold it fixed.

The quick start installs from master while the project asks products to pin a release

Step 1 of the quick start pulls three files from the master branch with wget:

wget https://raw.githubusercontent.com/simdjson/simdjson/master/singleheader/simdjson.h https://raw.githubusercontent.com/simdjson/simdjson/master/singleheader/simdjson.cpp https://raw.githubusercontent.com/simdjson/simdjson/master/jsonexamples/twitter.json

Those URLs carry no tag, so the files you compile are whatever master holds at the moment you run the command. The project states the opposite preference a few lines earlier: if you are planning to use simdjson in a product, please work from one of our releases. The tags make that possible. v5.1.1 was cut on November 1, 2026, v5.1.0 on October 30, 2026, v5.0.8 on October 29, 2026, and the last commit to the repository is dated November 2, 2026. The repository is not archived and work is landing on it, so nothing suggests abandonment. The catch is narrow but real: the branch the quick start points at and the release line you are told to build against are two different things, and the command above gives you no way to choose between them.

clang++ falls back to C++98 and the build command never passes a standard flag

Prerequisites are g++ at version 7 or better, or clang++ at version 6 or better, on a 64-bit system with a command-line shell such as Linux, macOS, or freeBSD. Visual Studio and Xcode are supported, though the quick start says different steps are needed and does not spell them out. Then comes the specific trap, named in the same paragraph: users of clang++ may need to specify the C++ version, for example `c++ -std=c++17`, since clang++ tends to default on C++98. The build step itself is a single line, `c++ -o quickstart quickstart.cpp simdjson.cpp`, and no standard flag appears in it. On a clang toolchain the printed command is therefore missing the one option the project just described, and supplying it is left entirely to you. On Visual Studio or Xcode the whole quick start shape, two files and one compile line, does not apply, which means anyone on those tools has to find the CMake route in the repository instead.

Validation is full UTF-8 and exact numbers, with no documented way to turn it down

Strictness is listed as a headline property rather than an option: full JSON and UTF-8 validation, lossless parsing, performance with no compromises. The performance section states that to the authors' knowledge it is the first fully-validating JSON parser to run at gigabytes per second on commodity processors. The bill arrives at input time. Because full validation sits inside the documented default path with no switch exposed in the quick start or in the documentation index, documents that a laxer parser would wave through fail here instead. Validation does get measured on its own terms, though: the headline figures are minification at 6 GB/s, UTF-8 validation at 13 GB/s, and NDJSON at 3.5 GB/s, next to claims of 4x over RapidJSON and 25x over JSON for Modern C++.

The four-line main never inspects parser.iterate, so failures become the caller's problem

The quick start program is short enough to read in full, and it checks nothing:

#include <iostream>
#include "simdjson.h"
using namespace simdjson;
int main(void) {
    ondemand::parser parser;
    padded_string json = padded_string::load("twitter.json");
    ondemand::document tweets = parser.iterate(json);
    std::cout << uint64_t(tweets["search_metadata"]["count"]) << " results." << std::endl;
}

It declares an ondemand parser, loads twitter.json into a padded_string, calls parser.iterate, and prints a count; run against the bundled twitter.json it prints 100 results. No step inspects a return value and no step catches anything, and the padded_string is simply left to fall out of scope when main returns rather than being released by hand. The project treats error handling as a decision the caller makes, which the Godbolt section makes explicit with two separate examples built on simdjson 5.0.1, one handling errors through exceptions and one handling errors without exceptions, sitting next to a C++26 reflection example. Copy the quick start verbatim and you inherit an unchecked parse.

Compile-time parsing is C++26 only, far past the documented compiler floor

The documentation index lists a Compile-Time Parsing page that presents the compile-time parsing function and marks it C++26 only, and one of the three Godbolt examples, built against simdjson 5.0.1, is a C++26 reflection example. Everything else in the project still asks for g++ at version 7 or clang++ at version 6 on a 64-bit system. That gap is the real limit. The newest parsing path needs a toolchain far ahead of the documented floor, so on the compiler versions named in the quick start you simply do not have it. A library otherwise content on decade-old compilers puts one headline feature strictly out of reach until your build environment catches up, which is worth checking against your own toolchain before you plan around it.

Every published speed number is tied to Skylake, a named GCC, and -O3

The comparisons are specific rather than general. The library is said to parse JSON 4x faster than RapidJSON and 25x faster than JSON for Modern C++, and to use three-quarters fewer instructions than RapidJSON. It is also described as the first fully-validating JSON parser to run at gigabytes per second on commodity processors, able to parse millions of JSON documents per second on a single core. The project itself is current, with a last commit dated November 2, 2026 and three recent releases.

The package and bindings sections are named in the table of contents but never shown

The README's table of contents names Packages, Bindings and Ports of simdjson, About simdjson, Funding, Contributing to simdjson, and License, so package-manager and language-port listings have their own sections, separate from the quick start, which covers only the single-header C++ path. The top-level tree does reveal the shape of the development repository: benchmark/, cmake/, dependencies/, doc/, examples/, extra/, fuzz/, include/, jsonexamples/, p2996/, scripts/, singleheader/, src/, style/, tests/, tools/, and windows/, sitting beside LICENSE, LICENSE-MIT, SECURITY.md, AI_USAGE_POLICY.md, and HACKING.md, all under an Apache-2.0 license.

Editorial conclusion

Pick simdjson when JSON throughput is the bottleneck and you control both your release tag and your compiler flags, which is exactly why the project tells you to build from a release rather than the master branch the quick start downloads from. Before committing, read doc/implementation-selection.md to learn how your target CPUs decide which parser they run.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. simdjson/simdjson on GitHub