UnityGLTF: the flexible glTF 2.0 option for Unity, from Khronos itself

Import and export, in the editor and at runtime

The library's pitch fits in a four-cell table. Both Import and Export are supported, both in the Editor and at Runtime. That combination is rarer than it sounds. Most Unity glTF tooling is an editor-only importer that bakes a scene, and anything that could load a model at runtime was usually a separate package with a different feature set.

The package identifies itself as `org.khronos.unitygltf` in `package.json`, version 2.21.0, authored by Khronos Group, with a declared minimum Unity of 2021.3. It is MIT licensed, has 2,236 stars and 537 forks, and was last pushed on 2026-09-24.

The dependency list in `package.json` is short and tells you the implementation approach: `com.unity.nuget.newtonsoft-json` for JSON, plus the audio, imageconversion, particlesystem, shadergraph, mathematics and collections modules. No native library appears anywhere. The README is explicit that UnityGLTF has no native dependencies, is pure C#, and therefore works on all platforms Unity supports, which it calls out specifically to include WebGL import and export.

That single property is the strategic decision. It means the package can be consumed inside a browser build, which is not true of every glTF path in Unity, and it means the same code path serves editor tooling and shipped clients rather than two divergent ones.

How it installs, and how you pin a version

Two routes are documented. The first is a one-click `.unitypackage` installer for the Needle Package Registry, which you download, drop into Unity and follow the steps. The second is direct from git through Unity Package Manager, which is the more reproducible of the two. You open `Window > Package Manager`, click the `+` button, select Add Package from git URL, paste the URL, and click Add:

https://github.com/KhronosGroup/UnityGLTF.git

The README notes that you can append `#release/<some-tag>` or a specific commit to target an exact version, and gives `release/2.14.1` as the example, which is a useful detail because the tag naming here includes a `release/` prefix rather than a bare version.

Version history is reasonably active and the tags move independently of the manifest version. Recent releases include 2.20.0 in July 2026, 2.19.2 in March 2026, and a 2.19.1 that added webP texture import, which requires a separate package, and EXR texture import, which requires Unity 6 or newer. Worth noting for planning: the version in `package.json` at the head of the branch is 2.21.0, ahead of the newest tagged release.

Where UnityGLTF and glTFast part ways

The README has a dedicated section on this, and it is the most useful paragraph in the document because the two libraries sit in the same package registry solving the same problem.

The short version: glTFast is built on Unity-specific performance machinery, notably Burst and Jobs, and because Unity supports it directly it has to hold to the ratified standard fairly strictly. It cannot easily ship non-ratified or experimental extensions that would work for most users. UnityGLTF takes the opposite position. It aims to be the flexible framework, with extensive import and export plugin support, plugins that work out of the box, and a deliberate willingness to ship extensions such as `KHR_animation_pointer`, `KHR_audio` and `KHR_materials_variants`.

There is a real trade here, not a marketing one. glTFast can have better performance in some cases and has better HDRP support. UnityGLTF gives you the plugin infrastructure to modify import and export heavily to fit a specific pipeline.

They can coexist in the same project. You can use glTFast for import and UnityGLTF for export, and there is a dropdown for choosing which importer handles an asset, though glTFast import takes precedence if both are installed. The README also links a Default Importer Selection section for controlling that.

Render pipeline support stated honestly

The badge row at the top of the README is unusually candid about where this does not work well.

URP is supported. Built-in Render Pipeline is supported, with better support on 2021.3 and later. HDRP carries a yellow badge reading that support is not actively maintained. The compatibility section repeats it: HDRP currently has limited functionality.

On the Unity version axis, the recommendation is to use Long-Term Support releases, specifically 2021.3, 2022.3 and 6000.0 or later, in linear colorspace. The README adds a warning that issues on non-LTS versions will most likely not be addressed, which is a direct statement about where the support effort goes.

For Unity 2020.3 users there is a concrete answer rather than a shrug: use an older UnityGLTF such as 2.9.1-rc or before. Gamma colorspace still works for import and export but is flagged as no longer maintained.

If your project is on HDRP, the honest summary is that you should be using glTFast instead, since its better HDRP support is one of the two things the README says it does better.

The plugin layer is the actual product

The design intent stated up front is that the library is easy to extend with additional glTF extensions, and that both import and export allow attaching custom plugins and callbacks and can be heavily modified to fit specific pipelines. The README ships worked examples for both a custom export plugin and a custom import plugin under its Extensibility heading.

That matters because the feature list is long and the list is not the interesting part. Import and export both cover animation and Animator with multiple clips, skinned mesh renderers, blend shapes including sparse accessors, linear and gamma colorspace, vertex colors, and cameras in both perspective and orthographic projection. The text is careful to say these lists are non-conclusive and in no particular order, and it names the shape of the gaps directly: there are places where a feature could easily be supported for import or export but currently is not, and pull requests are welcome.

Two adjacent features show how far this goes. KHR_interactivity export arrived as an official part of the library in 2.20.0 through a new Visual Scripting exporter plugin, and the changelog shows interactivity work continuing across several releases with slerp nodes, matrix serialization switched to column-major order, and AnimationClip.length support. Separately, blend shape export is a named feature, and material handling has a whole README section covering conversions, shader export compatibility, and per-pipeline setup for refractive materials under transmission and volume.

Where to start and what the docs leave open

For import there are two documented paths. The runtime route is a Gltf component, which can be placed on a GameObject to load a file, or it can be driven from code, and there is a load-via-code example in the README. The editor route is a normal asset import. One operational detail catches people: the README has a section on ensuring shaders are available in your build, because a material that resolves fine in the editor can lose its shader once code stripping runs in a player.

Animation import is handled separately in the changelog and the feature list, and animation export has four documented routes: the Animator Controller, a GLTFRecorder API, a Timeline Recorder, and a legacy animation component, plus `KHR_animation_pointer` support. WebP and EXR texture support arrived in 2.19.1 with the external package and Unity 6 requirements noted above.

The repository structure is the usual three-part Unity package layout: `Editor/`, `Runtime/` and `Tests/`, with a `CHANGELOG.md`, a `LICENSE` and `CODE_OF_CONDUCT.md`. Contributing guidance points at a Unity Package section, a GLTFSerializer section and a Tests section.

What the README does not settle is how any of this behaves on a large asset library. The changelog mentions deduplication statistics and mesh deduplication speedups with Jobs, and reduced memory footprint on texture import for non-memory streams, but there are no published numbers. If deduplication and memory behaviour are what you are buying this for, those entries tell you the work is happening without telling you how much it buys.

Editorial conclusion

UnityGLTF is the right pick when your pipeline needs extensions Unity has not ratified, when you need export as much as import, or when WebGL is in scope since there are no native dependencies to block it. glTFast is the faster option and has the better HDRP story, and the two can coexist in one project. The gaps to know about before committing: HDRP is limited, gamma colorspace is no longer maintained, and the plugin surface is where you will end up writing your own code.

Frequently asked questions

Official sources

1. Issues
2. KhronosGroup/UnityGLTF on GitHub
3. License: MIT
4. README
5. Releases