# Microsoft glTF-SDK: a C++ deserializer with schema validation built in > The glTF-SDK is Microsoft's C++ library for reading and writing glTF and GLB, with embedded Base64 support, strongly typed extensions, validation during deserialization and utilities for normalising input data. It is a native library rather than a loader for one engine, and the newest tagged release in the repository is from 2023. **microsoft/glTF-SDK** — glTF-SDK is a C++ Software Development Kit for glTF (GL Transmission Format -https://github.com/KhronosGroup/glTF). - Repository: https://github.com/microsoft/glTF-SDK - Stars: 631 · Forks: 113 - Language: C++ - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-gltf-sdk ## What the SDK is, and what it deliberately leaves out The glTF-SDK is a C++ Software Development Kit for glTF, the GL Transmission Format maintained by the Khronos Group, and the README describes it as a C++ deserializer and serializer for glTF. The feature list is short and each item is a design decision. It is Windows, macOS and Android compatible, and the project also supports Linux development. It handles glTF and GLB, including embedded Base64 support, which means a self-contained binary asset needs no separate buffer files. It offers flexibility and ease of integration to any 3D engine, strongly typed extension support, built-in schema validation during deserialization, low memory overhead, and utilities for converting input data of any type, for example float, uint8 or uint16 RGB or RGBA colour, into a single type such as float RGBA colour. The last two items are the ones that separate this from a format parser. A parser that only parses tells you the file is malformed. An SDK that validates during deserialization tells you the file is malformed and refuses to hand you a half-built scene graph, and a set of conversion utilities tells you that the artist's colour space choice is not going to reach your renderer as the type your renderer wants. What is not in the list is as informative. There is no scene management, no material system, no renderer, no animation player, and no asset pipeline. This is a library for getting glTF data into your program, not a program. The licence is MIT, the default branch is master, the repository is not archived, and the last push was on 2026-09-08. ## Building with CMake into a separate directory The build instructions assume a developer comfortable with native builds, and the required tools are listed: git, CMake at version 3.x, and PowerShell. Development is supported on Windows, macOS and Linux. The first step is to clone the repository: ```bash git clone https://github.com/microsoft/glTF-SDK.git ``` The build system is based on CMake, which customarily uses a separate build directory, and the location of that directory is up to you, but the README highly recommends using the Built directory from the repository root, and the .gitignore file is already set up to ignore it. That is a small courtesy that saves a step, and it is the reason the repository listing shows a Build directory. Configuring and building are two commands: ```bash cmake -B Built ``` ```bash cmake --build ./Built --target install --config Debug ``` The install step puts all binaries produced by the repository into a Built/Out directory, and the README enumerates what that means: the static library, the Serialize and Deserialize applications, and the GLTFSDK.Test test application. So the build gives you three things beyond the library itself, two command line tools for round-tripping files and a test binary. One constraint is stated in a note and is worth checking before you plan a build pipeline: CMake 4.0 or higher is not currently supported. ## The test binary and the shape of the repository Running the tests is a single command from the GLTFSDK.Test installation folder, and it writes the results as XML: ```bash .\GLTFSDK.Test.exe --gtest_output=xml:GLTFSDK.Test.log ``` The gtest output flag is the GoogleTest convention, which tells you the test application is built on GoogleTest and that the XML is for a CI reporter to pick up. The repository layout is organised by responsibility rather than by language, and reading the top level tells you what the project is made of. There is GLTFSDK/ for the library itself, GLTFSDK.Test/ for the test application, GLTFSDK.TestUtils/ for the shared test helpers, and GLTFSDK.Samples/ for the sample code. Outside the source tree there is an External/ directory for third-party dependencies, a Build/ directory, thirdPartyNotices.txt, a NuGet.Config, a CMakeLists.txt at the root, and a SECURITY.md. The samples directory deserves a note for anyone evaluating the SDK. A deserializer is one of those libraries where the API documentation tells you the names of the types but not how the pieces fit together, and sample code is usually where that is answered. The presence of a dedicated samples project rather than a scattering of snippets in the README suggests the authors took that seriously. The Microsoft-specific bits are visible in the project conventions. Contributions require agreeing to a Contributor License Agreement, and the project has adopted the Microsoft Open Source Code of Conduct. The glTF trademark note is explicit: glTF is a trademark of The Khronos Group Inc, which is worth keeping in mind if you are putting the word on marketing material rather than in a file format. ## Extensions and the risk of a stale tag The release history is the part of this project that deserves the most attention from a prospective adopter, because the tags are old relative to the recent push. The tagged releases are r1.9.5.9 from 2023-11-08 with the note Add new extensions, r1.9.6.0 from 2022-07-19 which added an MSVC flag guard, and r1.9.5.5 from 2021-11-11 which expanded the ReadSparseBinaryData index check to check for overflow. The last push was on 2026-09-08, so work is happening on master, but there has been no tag for it. Two things follow from that. First, if you take a tag you are taking 2022 or 2023 code, and the extension support in particular is what moves with the glTF specification, since extensions are added over time and the release note for the newest tag literally says it added new extensions. Second, if you take master you are taking unreleased code with no version number to pin, which is a different kind of problem. The bug fix titles are a useful signal about where the sharp edges are. The r1.9.5.5 change is an index overflow check in sparse binary data handling, and sparse accessors are exactly the kind of thing where an unchecked index is a memory safety bug rather than a wrong number. The r1.9.6.0 change is an MSVC flag guard for exception handling, which is a build compatibility fix on a specific compiler. Neither tells you the library is dangerous, and both tell you that this is native C++ code where the fix history reads the way you would expect for a parser of binary formats. The practical approach is to check the extension list in the version you plan to use against the extensions your assets actually use, and to treat the newest tag as the safe floor rather than the newest commit. ## Where the glTF-SDK is the wrong choice The first limitation is the platform. This is a C++ library with a C++ build, and the repository has no JavaScript, Python or Rust path. The wider glTF ecosystem is full of loaders that ship in the language of the engine they serve, and if your project is a web viewer, a Unity title or a Python tool, the SDK is not a dependency you can take, it is a porting project. The second limitation is that the SDK reads and writes files, and nothing more. It does not decide what your assets should be, it does not compress them, it does not generate LODs, it does not run a Draco or Meshopt pipeline, and it does not tell you that a mesh has too many triangles for your target. A team that is trying to solve an asset pipeline problem with this library is solving the wrong problem, and the honest answer for that case is a pipeline tool plus a lightweight loader. The third limitation is the maintenance shape. This is a C++ project with a build step, a Visual Studio and PowerShell in the toolchain list, a CMake version ceiling, and tags that stopped in 2023. That combination is fine for a studio with a C++ build pipeline already, and it is a recurring cost for a team whose main language is something else. The real alternative is the loader that already ships with your engine, and the difference in approach is exactly the trade the feature list makes explicit. An engine loader is free, maintained alongside the engine, and knows about that engine's material system and conventions, but it validates less and gives you less control over what the deserializer accepts. The SDK charges you for integration effort and buys you validation during deserialization, typed extension support, and the flexibility to convert input data into the single type your renderer wants, which an engine loader will not do for you. So the test is narrow. If you are writing C++ and you have hit the point where the engine loader either accepts a malformed file or hands you a colour in a format you did not ask for, the SDK is the right tool. If neither of those is true, it is a heavier way to read a JSON file with a binary buffer beside it. ## Conclusion Adopt the glTF-SDK if you are writing a C++ application that loads glTF assets and want validation at deserialization time, a single library that handles both glTF and GLB across Windows, macOS, Android and Linux, and typed extension support you would otherwise write yourself. Do not adopt it for a web or engine-ecosystem project, since there is no JavaScript or Python path here, and do not expect it to manage your asset pipeline, because it reads and writes files rather than deciding what belongs in them. Before you start, check the CMake requirement, since the README states that CMake 4.0 or higher is not currently supported, and confirm that the extensions you rely on are covered by the version you take. ## FAQ ### What is the Microsoft glTF-SDK? It is a C++ Software Development Kit for glTF, the GL Transmission Format from the Khronos Group, providing a deserializer and serializer for glTF and GLB with embedded Base64 support, strongly typed extension support, built-in schema validation during deserialization and low memory overhead. It is MIT licensed and runs on Windows, macOS, Android and Linux. ### How do I build the glTF-SDK? Clone the repository, configure with cmake -B Built using the Build directory from the repository root, which the .gitignore already ignores, then build and install with cmake --build ./Built --target install --config Debug. The README notes that CMake 4.0 or higher is not currently supported, and the required tools are git, CMake 3.x and PowerShell. ### How do I run the glTF-SDK tests? Run the test application from the GLTFSDK.Test installation folder with .\GLTFSDK.Test.exe --gtest_output=xml:GLTFSDK.Test.log, which writes the results as XML for a CI reporter. The test project is built with GoogleTest, and the install step also produces the static library and the Serialize and Deserialize applications. ### What is the latest release of the Microsoft glTF-SDK? The tagged releases are r1.9.5.9 from 2023-11-08, r1.9.6.0 from 2022-07-19 and r1.9.5.5 from 2021-11-11, while the last push to the repository was on 2026-09-08. Since the newest release note is about adding new extensions, the version you choose should be checked against the extensions your assets use. ### Does the glTF-SDK support embedded Base64 data and extensions? Yes. The README lists glTF and GLB support including embedded Base64 support, and strongly typed extension support as separate features. It also includes utilities for converting input data of any type, such as float, uint8 or uint16 RGB or RGBA colour, into a single type such as float RGBA colour. ## Sources - [Issues](https://github.com/microsoft/glTF-SDK/issues) - [License: MIT](https://github.com/microsoft/glTF-SDK/blob/master/LICENSE) - [microsoft/glTF-SDK on GitHub](https://github.com/microsoft/glTF-SDK) - [README](https://github.com/microsoft/glTF-SDK/blob/master/README.md) - [Releases](https://github.com/microsoft/glTF-SDK/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-gltf-sdk