GLB vs glTF
Compare GLB and glTF packaging, external buffers, textures, portability, version control, and common transfer problems before sharing an asset.
Applies to Tridi Viewer 1.4.0 release. Release notes
Quick answer
GLB stores the glTF JSON document and binary resources in one binary container. glTF normally uses a readable JSON file that can reference a separate .bin buffer and external image files. Both represent the same glTF 2.0 scene model; the main difference is packaging.
| Consideration | GLB | glTF |
|---|---|---|
| Typical files | One .glb container | .gltf, optional .bin, and images |
| Sharing | Convenient as a single file | Requires the referenced folder structure |
| Manual inspection | Binary container needs a tool | JSON can be opened in a text editor |
| Version control | Binary changes are harder to diff | JSON changes can be reviewed more easily |
| Texture replacement | Often requires repacking the container | External images can be replaced in place |
The scene data is still glTF
Geometry accessors, nodes, scenes, PBR materials, textures, skins, animation, morph targets, cameras, and extensions use the same glTF concepts in either package. Converting between GLB and glTF should change how resources are stored, not the intended scene.
A file can still depend on extensions or unsupported data even when it is packaged as one GLB. “Single file” does not guarantee that every viewer supports every extension used by the asset.
Choose GLB for simple distribution
GLB is usually the practical choice when you want to send one file, attach an asset to an issue, archive a self-contained delivery, or reduce the chance that a separate buffer or texture folder is lost. It is also convenient for drag-and-drop workflows and web delivery when the runtime accepts a binary glTF container.
Confirm that the exporter embeds the intended images and buffers. External network resources, unusual extension payloads, or application-specific metadata can still make a package behave differently from a fully portable core glTF asset.
Choose glTF for editable dependencies
A JSON-based .gltf package is useful when artists or developers need to inspect URIs, replace textures without rebuilding a container, review JSON changes in version control, or debug how buffers, images, materials, and extensions are connected.
Keep every referenced file at the relative path recorded in the JSON. Renaming the .bin file, moving an image folder, changing letter case, or sharing only the .gltf document can leave geometry or textures missing.
Common transfer and import problems
- A
.gltffile arrives without its external.binbuffer. - Texture files were moved, renamed, recompressed, or excluded from the delivery.
- Required extensions are unsupported and the asset has no core fallback.
- Draco- or Meshopt-compressed geometry or KTX2/Basis textures have no supported fallback.
- Absolute, encoded, or case-sensitive resource paths no longer match the receiving system.
Inspect GLB and glTF in Tridi Viewer
Open either format and inspect the hierarchy, materials, texture channels, UV sets, animation clips, morph targets, wireframe, and render passes supported by the importer. If geometry appears without textures, check external dependencies before editing the material.
Use the GLB and glTF viewer guide for supported data and extension limits, Auto Find Textures for local image matching, and Supported 3D formats for the current compatibility summary.
Format reference: the Khronos glTF 2.0 specification defines the JSON representation, GLB container, buffers, images, materials, animation, and extension rules.