glTF was designed as a transmission format for real-time 3D — compact, quick to parse, and built around modern PBR rendering. It has become the default for the web and is increasingly the default everywhere else.
The two variants
- .gltf — a JSON file, with geometry and textures either referenced as separate files or embedded as base64. Human-readable and editable.
- .glb — everything in one binary file. Smaller, faster to load, and the practical choice for distribution.
Same specification; the container differs.
What it carries
- Geometry, with multiple UV sets and vertex colours
- PBR materials — base colour, metallic, roughness, normal, occlusion, emissive
- Textures, embedded or referenced
- Skeletons, skinning and animation
- Morph targets
- Scene hierarchy, cameras and lights
- Extensions for anything beyond the core
Why it transfers materials well
Because it defines a material model rather than leaving it to interpretation. Two applications reading the same glTF agree about what "metallic 1, roughness 0.3" means. FBX predates PBR and approximates, which is why FBX materials so often need rebuilding.
Extensions
The core specification is deliberately small; extensions add compression, transmission, clearcoat, volume, variants and more. Support is uneven — an extension your exporter writes may be silently ignored by the importer, which is a quiet way to lose data.
Compression
Draco compresses geometry substantially; KTX2/Basis compresses textures into GPU-native formats. Both are worth enabling for web delivery and both add a decode step.
Limits
- No parametric data. It is a mesh format.
- Y-up, metres, right-handed by specification — which is a strength, since there is no ambiguity to negotiate.
- Extension support varies, so verify what actually arrives rather than what was exported.