yaml-cpp: YAML 1.2 for C++, with a 2026 deadline on its past

A parser and emitter that matches the spec

yaml-cpp is a YAML parser and emitter in C++ matching the YAML 1.2 specification, and both halves of that job description matter: it reads documents into a manipulable node structure and writes YAML back out, where many integrations only need the first half. The license is MIT, the interface is C++ rather than a C core with wrappers, and the project has been the default answer in its niche long enough that its history has generational layers, an old API through the 0.3.x line, a new API from 0.5.0 onward, and a stated policy that the old API will stop receiving bugfixes in 2026. The current release is 0.9.0 from 2026-02-04, with the repository last pushed on 2026-09-17, so the deadline and the maintenance both remain live concerns.

CMake with three flags that matter

The build is CMake-based for cross-platform support, and the documented entry point is minimal:

mkdir build
cd build
cmake [-G generator] [-DYAML_BUILD_SHARED_LIBS=on|OFF] ..

The generator selects the build system, with Visual Studio variants named for Windows, Xcode on macOS, and plain Makefiles on Unix when the option is omitted. The library builds static by default, switched to shared with -DYAML_BUILD_SHARED_LIBS=ON, and the third flag that matters is Windows-specific: on MSVC, static builds default to the static CRT, /MT, so yaml-cpp can link into statically-linked applications such as static MFC, with -DYAML_MSVC_SHARED_RT=ON selecting the dynamic CRT instead. Cleaning up is stated with the same economy, remove the build directory. Further customization lives in CMakeLists.txt rather than a growing README.

FetchContent and the imported target

Modern CMake integration is one documented block, pulling the source directly into your build:

include(FetchContent)

FetchContent_Declare(
  yaml-cpp
  GIT_REPOSITORY https://github.com/jbeder/yaml-cpp.git
  GIT_TAG <tag_name> # Can be a tag (yaml-cpp-x.x.x), a commit hash, or a branch name (master)
)
FetchContent_MakeAvailable(yaml-cpp)

target_link_libraries(YOUR_LIBRARY PUBLIC yaml-cpp::yaml-cpp) # The library or executable that require yaml-cpp library

The yaml-cpp::yaml-cpp imported target is the linchpin: it sets the needed defines automatically, including the static-versus-dynamic bookkeeping, so consumers link one name instead of replicating flags. Projects not using CMake at all must define YAML_CPP_STATIC_DEFINE manually when linking the static library, the one escape hatch the README documents, and the tag comment's honest note that a branch name is accepted serves as a reminder that a pinned tag or commit hash is the reproducible choice.

The CRT, GLIBCXX_DEBUG and the GoogleTest caveat

The build documentation spends its depth on debugging corners, which tells you who its readers are. The libstdc++ debug mode can be used when yaml-cpp and client code are both compiled with _GLIBCXX_DEBUG, for example through CMAKE_CXX_FLAGS_DEBUG, turning iterator misuse into hard errors rather than corruption. The caveat is precise: for yaml-cpp's unit tests to run under that flag, GoogleTest must be built with the same flag, so the system package cannot be used, and YAML_USE_SYSTEM_GTEST must be OFF, which is the default. This is the kind of note that saves a day of mystifying test failures, and its presence signals that the project expects to be built in demanding environments, financial and embedded toolchains being the usual inhabitants of that corner.

Two APIs and the year one of them ends

The API story is split by a boundary everyone adopting the library must locate. The current interface is documented in the wiki's Tutorial and How to Emit YAML pages. Code written before 0.5.0 used a different API, documented separately as How To Parse A Document, Old API, and the 0.3.0 release remains available for those who need it. The policy line deserves to be quoted in effect: the old API will stop receiving bugfixes in 2026, which converts a historical footnote into an active migration task for any long-lived codebase still on the old node-iteration style. For new code the decision is trivial, there is only one API to learn, but for maintainers of older software the release notes of 0.9.0 and the wiki migration guidance are the reading list.

Bazel files, a pkg-config file and generated API docs

The repository's root shows a library that meets build systems where they live. BUILD.bazel, MODULE.bazel and its lockfile carry first-class Bazel support alongside the CMake path, so monorepos on either tool consume it natively. yaml-cpp.pc.in generates a pkg-config file for the Makefile-and-configure world, and yaml-cpp-config.cmake.in backs the CMake package config, meaning three consumption idioms are maintained rather than one blessed path. The API reference is autogenerated and hosted on CodeDocs, so the documentation tracks the headers without a manual publishing step, and SECURITY.md, CONTRIBUTING.md, .clang-format and .editorconfig round out a deliberately conventional open source posture. Nothing here is glamorous, and that is the point: a parsing library's job is to be dependable infrastructure.

Qt and Unreal wrappers, explicitly on their own

Two third-party integrations are listed with a disclaimer doing real work: the following projects are not officially supported. One is a Qt wrapper, published as a gist, wrapping yaml-cpp's types for Qt idioms. The other is UnrealYAML, a wrapper integrating the library into Unreal Engine projects. Listing them while disclaiming them is the honest middle ground, discoverable but unmaintained by upstream, and adopters in those ecosystems should read the disclaimer as a statement about update cadence as much as support. Release cadence itself is unhurried, 0.7.0 in 2021, 0.8.0 in 2023 and 0.9.0 in 2026, the rhythm of a finished library that moves when the spec, the toolchains or the bugs require it, with the util/ and test/ directories carrying the supporting machinery between releases.

Editorial conclusion

Use yaml-cpp when a C++ project must parse or emit YAML 1.2 and you want the library most of the ecosystem already links, with clean CMake and Bazel consumption. Consider libyaml when a plain C dependency fits better or language bindings build on it, since yaml-cpp is unapologetically a C++ API. Verify first that any legacy code is off the old API before the 2026 bugfix cutoff bites, pin an exact tag through FetchContent rather than a branch, and decide static versus shared linkage and the MSVC CRT flavor before your first distribution build.

Frequently asked questions

Official sources

1. Issues
2. jbeder/yaml-cpp on GitHub
3. License: MIT
4. README
5. Releases