What Is a GLB File? The Web 3D Format Powering AR, E-Commerce, and Game Engines

glTF (Graphics Library Transmission Format) is a 3D file format developed and maintained by the Khronos Group — the same consortium behind OpenGL, Vulkan, and WebGL. Initially released in 2015, glTF 2.0 (June 2017) introduced physically-based rendering (PBR) materials and became the format's landmark release. In July 2022, glTF 2.0 was formalized as ISO/IEC 12113:2022, making it an international standard.

GLB and glTF are two packaging variants of the same underlying format. A `.gltf` file is JSON text that describes a 3D scene — geometry references, material definitions, node hierarchy, animations — with binary mesh data and textures stored as separate external files (.bin, .jpg, .png). A `.glb` file is a binary container that packs the JSON, the binary mesh data, and optionally the textures into a single file. The content is identical; only the packaging differs.

Khronos coined the phrase "JPEG of 3D" for glTF/GLB — and it is an accurate comparison. JPEG made web images practical by finding the right balance between file size, quality, and universal support. GLB does the same for 3D: it is small enough for web delivery, high enough quality for product visualization and AR, and supported by every major platform — browsers via Three.js/Babylon.js/model-viewer, game engines (Unity, Unreal, Godot), AR platforms (Apple Vision Pro, Android ARCore), and cloud platforms (Google, AWS, Azure 3D services).

As of 2026, glTF/GLB is supported by over 200 tools and applications — including Blender (native export since 2.80), Adobe Substance Painter, Autodesk Maya, Apple's Reality Composer, Google's model-viewer, Facebook/Meta's 3D photo systems, and Shopify's 3D product visualization.

A GLB file is a binary container with a precise header structure defined by the glTF 2.0 specification. The 12-byte file header contains three 4-byte little-endian integers: magic (0x46546C67 — the ASCII bytes "glTF"), version (must be 2), and length (total file size in bytes). Following the header are one or more chunks.

The first chunk (always present) is the JSON chunk: a 4-byte little-endian chunk length, a 4-byte chunk type (0x4E4F534A — "JSON"), and the JSON payload padded to a 4-byte boundary with spaces. The second chunk (when present) is the binary buffer chunk: a 4-byte length, a 4-byte chunk type (0x004E4942 — "BIN\0"), and the raw binary data (geometry attributes, indices, animation data). Image data may be embedded directly in the binary chunk or referenced as external files.

This chunk structure means GLB files can be efficiently processed by streaming: a parser can read the JSON header in the first chunk to understand the scene structure, then sequentially read the binary data in the second chunk without loading the entire file into memory. For web delivery, this enables progressive loading patterns — a significant advantage for large scenes.

All buffer data in glTF uses little-endian byte order. Geometry attributes (vertex positions, normals, UVs, tangents) and vertex indices are stored as typed arrays directly compatible with GPU vertex buffers — this "zero-copy" design means assets can be uploaded to the GPU without format conversion, explaining the format's exceptional load-time performance compared to OBJ (which requires parsing ASCII numbers into binary floats) or FBX (which requires significant format conversion).

glTF 2.0's PBR (Physically Based Rendering) material system is one of its defining features. The core material model is metallic-roughness workflow: baseColorFactor or baseColorTexture (diffuse color/albedo), metallicFactor and roughnessFactor (packed into metallicRoughnessTexture, metallic in blue channel, roughness in green channel), normalTexture (surface bump detail), occlusionTexture (baked ambient occlusion), and emissiveFactor/emissiveTexture (self-illuminated surfaces).

This PBR model is identical to the material system used by Unreal Engine, Unity HDRP, Blender Cycles, and Disney's Principled BSDF — the de facto industry standard for physically accurate shading. When you export a model from Blender with its PBR materials to GLB, the material data is preserved exactly, with no conversion or approximation. This is fundamentally different from OBJ/MTL, which uses the older Phong shading model and requires manual material conversion.

Official glTF extensions further expand material capabilities: KHR_materials_transmission (glass and transparent materials), KHR_materials_clearcoat (automotive paint, varnished wood), KHR_materials_sheen (fabric microfiber simulation), KHR_materials_ior (physically accurate index of refraction), and KHR_materials_emissive_strength (HDR emissive for screens and lights). These extensions are optional — a GLB that uses them will render correctly in supporting viewers and gracefully degrade in older ones.

Texture compression within GLB is available through KHR_texture_basisu — an extension that stores textures in KTX2/Basis Universal format for GPU-native compression. This allows textures to be uploaded directly to the GPU without CPU decompression, typically reducing GPU memory usage by 4–8× compared to PNG/JPEG textures.

Google's Draco library (github.com/google/draco) compresses 3D mesh geometry through a process called attribute compression — reducing vertex positions, normals, texture coordinates, and color data with lossy quantization. The glTF extension KHR_draco_mesh_compression enables this compression inside GLB files.

Draco compression typically reduces vertex data by 60–90% — a 20MB GLB might become 3–5MB with Draco enabled. The trade-off is decode time: Draco requires a JavaScript (or WebAssembly) decoder to run in the browser before the geometry can be used. Modern implementations (Three.js DRACOLoader, Babylon.js) load the Draco decoder from a CDN and cache it, so the performance cost is a one-time decoder download (~120KB gzip) rather than per-model overhead.

For web deployment where bandwidth matters — product configurators, e-commerce 3D viewers, AR experiences — Draco compression is nearly always worth enabling. Polyvia3D's GLB Compress tool applies Draco compression to any GLB, with user-configurable quantization precision for the position, normal, UV, and color channels.

Alternative to Draco: MeshOpt (KHR_mesh_quantization + EXT_meshopt_compression) provides similar or better compression ratios with faster decoder performance (pure WASM, no large library). As of 2025, MeshOpt is gaining adoption in performance-critical applications. GLB files can contain either Draco or MeshOpt compression, not both simultaneously.

glTF/GLB is the only widely supported web 3D format with native animation support. Animations are defined as named clips, each targeting a specific node (object) with specific channels: translation (position), rotation (quaternion), and scale. Animation interpolation modes include linear, step (instant snap), and cubic spline for smooth motion curves.

Skeletal (bone-based) animation is supported through skins: a skin defines an array of joint nodes with inverse bind matrices. A mesh references a skin and provides joint indices and weights per vertex (up to 4 joint influences per vertex in the base spec, up to 8 with the KHR_mesh_gpu_instancing extension). This is the same skeletal animation system used in game engines.

Morph targets (blend shapes) are supported as alternative mesh primitives with different vertex positions, normals, or UV sets. Animation clips can drive morph target weights, enabling facial animation, clothing simulation, and other deformation effects.

The scene graph (node hierarchy) in glTF defines parent-child transform relationships. A node can have a transform (translation, rotation, scale — stored as separate TRS components, not as a 4×4 matrix) and optionally reference a mesh, camera, or skin. This explicit scene graph is why GLB preserves object hierarchies accurately when moving models between Blender, Unity, and web viewers — a significant advantage over OBJ (no hierarchy) and comparable to FBX (hierarchy preserved but format is proprietary).

When NOT to use GLB: If your pipeline requires legacy compatibility with applications that predate glTF 2.0 (some older industrial software), use OBJ or FBX. For 3D printing, use STL or 3MF — GLB has no concept of manifold mesh requirements or unit-based scaling conventions used by slicers. For archiving raw scan data, OBJ or PLY may be simpler. For proprietary game engine workflows deeply invested in FBX (e.g., complex Maya rig pipelines), FBX remains the better interchange format.

Web: Any modern browser supports GLB via Three.js, Babylon.js, or the HTML <model-viewer> web component. Google's model-viewer (model-viewer.dev) is a simple way to embed interactive GLB viewing in a web page with a single HTML tag. No plugins required.

Desktop: Blender, Godot, Unity, Unreal Engine, and many CAD applications support GLB natively. Windows 11's 3D Viewer, macOS Quick Look, and iOS/iPadOS Preview can all display GLB files.

Polyvia3D: The GLB Viewer opens any GLB file in the browser. The GLB Compress tool applies Draco compression to reduce file size for web delivery.

Common conversions: OBJ to GLB (add animations and smaller file for web), STL to GLB (3D printing geometry to web display), FBX to GLB (game asset for web deployment). Note: FBX to GLB conversion currently requires desktop software (Blender is free) — Polyvia3D plans to add FBX support in a future update.