# fastgltf: a C++20 glTF loader built around SIMD parsing

> fastgltf is an MIT licensed C++20 library for loading glTF 2.0 models, using SIMD to cut parse time, exposing typed accessors and offering a named module build. It supports the whole specification, defaults to doing the minimum with a model, and requires a tagged release rather than the main branch.

**spnda/fastgltf** — A modern C++17/C++20 glTF 2.0 library focused on speed, correctness, and usability

- Repository: https://github.com/spnda/fastgltf
- Website: https://fastgltf.readthedocs.io/v0.9.x/
- Stars: 613 · Forks: 98
- Language: C++
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/spnda-fastgltf

## A loader that treats parsing as the bottleneck

fastgltf is described as a speed and usability focused glTF 2.0 library written in modern C++20 with minimal dependencies. The stated mechanism for the speed is SIMD, used in various areas to decrease the time the application spends parsing and loading glTF data.

That is a specific and unusual claim for a glTF library, because the slow part of loading a model is usually not the file format itself. A glTF file is JSON describing buffers, and the work is dominated by reading and parsing that JSON, then decoding accessor data from the binary buffer. Which is exactly where SIMD pays off, and it explains the choice of dependencies.

Two libraries are embedded in fastgltf, simdjson and simdutf, both under the MIT licence. simdjson is a JSON parser built around vectorised instructions, and simdutf is the UTF-8 validation library that a parser like that needs. The list of libraries used in the examples and the tests is longer, with Catch2 under BSL-1.0, glad under MIT, glfw under Zlib and glm under MIT, which is the standard set for a small OpenGL demonstration.

The second half of the pitch is the language. By taking advantage of modern C++20 the library provides easy and safe access to the properties and data, and it is also available as a C++20 named module. For a codebase that has already moved to modules, a library that can be imported as `import fastgltf;` rather than included as a header is a materially different integration experience.

## The whole specification, and a deliberately minimal default

The scope claim is that the library supports the entirety of the glTF 2.0 specification, including many extensions. That is a stronger claim than most loaders make, because it implies the extension handling is not a curated subset.

The default behaviour is the opposite of maximal. By default, fastgltf will only do the absolute minimum to work with a glTF model. The philosophy is that a loader should not silently do work the application did not ask for, and that the expensive or opinionated operations should be opt in.

On top of that minimum the library adds features meant to ease working with the data, and three are worth naming because they save real work in a renderer. There are accessor tools, which handle the awkward parts of reading typed data out of an accessor rather than making every application decode the buffer format itself. There is the ability to directly write to mapped GPU buffers, so a mesh's vertex data can go straight into a buffer the graphics API has mapped. And there is decomposing transform matrices, which is the operation every scene graph needs when it wants to apply a node's transform to positions rather than keeping a matrix around.

The combination is a coherent position. Parse as little as possible by default, then hand the caller typed data, GPU ready buffers and decomposed transforms when asked. The trade is that a project wanting a different default, for instance one that always wants RGB colours computed from spherical harmonics, has to ask for it explicitly rather than accept a policy.

## Version choice matters more than usual

The README carries two notes that any adopter should read before anything else.

The first is about the language standard. For C++17 compatibility, use v0.9.x. Later versions require C++20. That is a hard boundary and it is the kind of detail that decides whether a library can be used at all, since a project still on C++17 has no way to take the newer releases without a toolchain change of its own.

The second note is about which source to build from. The instruction is to always use a released version, either through vcpkg or Conan or by checking out a tagged release, because the main branch is under active development and may contain broken or incomplete changes.

That warning is unusual to see stated so bluntly, and it is a good indicator of the project's character. A library where the development branch is knowingly unstable is a library where a packaging manager is close to mandatory rather than convenient, because the package manager gives you a versioned artefact and a source tarball, and a tagged checkout gives you the same thing without depending on anyone else's release cadence.

The release history explains the version numbers. v0.9.1 is dated 2026-09-27, v0.9.0 from 2025-07-08 and described as the v0.8 anniversary edition, and v0.8.0 from 2024-07-25. The v0.9 line is therefore the current one, and it is the line to use if C++17 compatibility matters. The repository is not archived and the last push was on 2026-10-19, so the branch is being worked on, just not in a form you are meant to consume.

The documentation badges make the same point about where the truth lives, with the versioned documentation URL pointing at the v0.9.x branch of the docs rather than at latest.

## Where the library comes from and what it embeds

fastgltf is available through the two usual C++ package managers, with badges for both vcpkg and Conan, and it can of course be built from a tagged release with CMake. The repository layout is that of a CMake project: a `CMakeLists.txt` at the root, a `cmake/` directory for the build modules, `include/` for the public headers, `src/` for the implementation, `tests/`, `docs/` and `examples/`, plus a `.readthedocs.yaml` for the documentation build and a `.gitmodules` file.

The examples directory contains small demos showing how to integrate fastgltf into a 3D renderer, with a `gl_viewer` example and its own `CMakeLists.txt`. There is no install command in the project description, so the practical answer to how to obtain the library is the one the README gives: vcpkg, Conan, or a tagged checkout.

The embedded dependencies deserve a closer look than a list of names. simdjson and simdutf are compiled into fastgltf rather than linked as separate dependencies, and both are MIT licensed, so there is no copyleft obligation in the output of a project that uses the library. That is the practical reason the minimal dependencies claim in the description is credible: the dependency surface is two MIT libraries that ship inside the library, not a tree of transitive packages that a user has to resolve.

The CI configuration is worth noticing too, because it tells you what the project actually tests. There are separate workflow badges for x64, ARM, macOS, sanitizers and modules, so the library is built and run on more than one architecture, is exercised under sanitizers, and the C++20 module build is tested as its own target rather than being assumed to work because the header build does.

## Adoption in engines, tools and embedded graphics

The README keeps a curated list of notable projects that use fastgltf, and reading it tells you the range of contexts the library is expected to work in.

There are rendering engines, among them Castor3D, described as a multi-OS 3D engine, and Raz, a modern multiplatform 3D game engine in C++17, which is a good sign for a library where the C++17 line still matters. There is Fwog, whose examples are a modern OpenGL 4.6 abstraction, and vk-gltf-viewer, a high performance glTF renderer made with Vulkan, plus Timberdoodle, a research focused 3D rendering engine made with Vulkan. There is a tutorial project, vkguide, and OptiX_Apps, the official NVIDIA samples for the NVIDIA OptiX Ray Tracing SDK.

Two entries stand out as different in kind. lvgl is an embedded graphics library for any MCU, MPU and display type, which shows the library being used where memory and platform constraints are tight. And wad2gltf is a WAD to glTF converter that showcases fastgltf's exporting functionality, which is worth noting because the project is usually described as a loader.

The list is curated rather than exhaustive, and the project asks that additions be proposed by private message or pull request so that the list stays a set of notable or widely useful references. That is a reasonable editorial policy for a reference list, and it also means the list is not a measurement of how widely the library is used. The Vulkan and embedded entries are the useful signal: the library is being taken to places where loading speed and memory behaviour actually matter, not just to desktop tools.

## What fastgltf does not do for you

The boundary of the library is worth stating plainly, because the name suggests more than it is.

It is a loader, with some export support. It does not provide a renderer, a scene graph, a material system or a physics layer, and the example set is a gl_viewer and a converter rather than an engine. If a project needs a complete 3D pipeline, the library is one component of it, and the projects on the usage list are the ones that supply the rest.

It also does not hide the glTF format from you. The data model is the specification's data model, with accessor tools to make the buffer handling less painful rather than an abstraction over the whole format. An application that needs to understand materials, skins, animations and the extension set in detail is still reading glTF, and the library's job is to get those bytes into memory quickly and hand them over with types attached.

The remaining sharp edges are the ones already named: the C++ standard floor, the warning against consuming the main branch, and the need to check that a given version of the library matches the C++ standard and package manager version your build is pinned to. None of these are flaws in the design, but they are the practical cost of a fast-moving library at version 0.9.

## Conclusion

fastgltf suits a C++ renderer, tool or embedded project that loads glTF 2.0 models and wants the parsing done with SIMD rather than a general purpose JSON library, and that is prepared to track a library where the C++ standard requirement moved from 17 to 20. It does not suit a team on C++17 that needs current features, because only the v0.9.x line supports that standard. Before depending on it, pin a tagged release rather than the main branch, as the project warns, check the vcpkg or Conan version you would actually get, and confirm that the extra helpers you need, such as direct GPU buffer writes and transform decomposition, are enabled rather than assumed.

## FAQ

### Does fastgltf support C++17?

Only the v0.9.x line. The project states that for C++17 compatibility you should use v0.9.x, and that later versions require C++20.

### How should I get fastgltf for my project?

The project states that you should always use a released version, either through vcpkg or Conan or by checking out a tagged release, because the main branch is under active development and may contain broken or incomplete changes. The repository has no install command of its own.

### What does fastgltf do by default when loading a glTF model?

By default it will only do the absolute minimum to work with a glTF model. Additional helpers such as accessor tools, writing directly to mapped GPU buffers and decomposing transform matrices are available on top of that.

### Which libraries are embedded in fastgltf?

simdjson and simdutf, both licensed under MIT. The examples and tests additionally use Catch2 under BSL-1.0, glad under MIT, glfw under Zlib and glm under MIT.

### Is fastgltf available as a C++20 module?

Yes. The project states that it is also available as a C++20 named module, and the CI configuration includes a dedicated modules workflow alongside the x64, ARM, macOS and sanitizers builds.

## Sources

- [License: MIT](https://github.com/spnda/fastgltf/blob/main/LICENSE)
- [Project website](https://fastgltf.readthedocs.io/v0.9.x/)
- [README](https://github.com/spnda/fastgltf/blob/main/README.md)
- [Releases](https://github.com/spnda/fastgltf/releases)
- [spnda/fastgltf on GitHub](https://github.com/spnda/fastgltf)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spnda-fastgltf