GLB vs glTF: File Structure, MIME Types, and When to Use Each

The most useful rule of thumb is simple: use GLB when you need one file to upload, ship, cache, or hand to someone else. Use glTF (`.gltf`) when you need to inspect the scene JSON, swap textures without repacking, or plug the asset into a build pipeline that already manages many related files.

GLB and glTF are not competing 3D standards. They are two packaging variants of the same glTF 2.0 format from the Khronos Group. The underlying 3D payload — geometry, materials, textures, animations, and scene hierarchy — can be identical in both. What changes is how that payload is stored on disk and delivered over the network.

glTF (`.gltf`) stores the scene description as human-readable JSON, then references mesh buffers and textures as separate files. GLB (`.glb`) packs that JSON plus the binary data into one binary container. Renaming a `.gltf` file to `.glb` does not work, because the binary container layout is different; you have to repack the asset properly.

At the engine level, major glTF 2.0 loaders such as Three.js, Babylon.js, and model-viewer understand both packaging variants. But product uploaders, CMS fields, and marketplace forms often accept only GLB because single-file uploads are much simpler than coordinating JSON + BIN + texture companions.

Want to see the difference in practice? Use Polyvia3D's free GLB ↔ glTF converter — upload any file and convert between the two packaging variants instantly, with no data uploaded to any server.

glTF JSON format: A `.gltf` scene consists of at minimum one JSON file, optionally a `.bin` binary file (for mesh data and animation data), and optionally one or more image files (for textures). The JSON file is the "index" — it describes the scene and references the external files by relative path. This multi-file structure means you cannot move or share a `.gltf` file without also moving its companions.

Alternatively, a glTF JSON file can embed binary data and images directly using data URIs (base64-encoded strings within the JSON). This creates a self-contained file but dramatically increases file size — base64 encoding adds approximately 33% overhead. Self-contained glTF JSON files are rarely used in practice.

GLB binary format: A `.glb` file is a single binary container with a 12-byte header (magic "glTF" + version 2 + total length), followed by chunks. The first chunk is always the JSON chunk (the same scene description JSON as glTF, but stored in binary framing). The second chunk, if present, is the binary buffer chunk (mesh data, animation data). Images may be embedded in the binary chunk or referenced as external files in the JSON. A fully self-contained GLB with embedded textures is a single distributable file.

Size comparison: Because GLB uses binary framing and can pack textures more efficiently than base64-in-JSON, a fully self-contained GLB is typically 10–20% smaller than a self-contained glTF JSON file with embedded data URIs. However, compared to glTF with separate external files (the most common glTF usage pattern), GLB with embedded textures is larger — because the separate files can be individually cached by browsers.

Measured example using Polyvia3D's converter: a mid-complexity architectural model with PBR textures (4 materials, ~12K triangles) converted from glTF+bin+textures to GLB. The glTF package (JSON + .bin + 3 texture files) totaled 2.84 MB across 5 files. The resulting GLB was 2.31 MB as a single file — an 18.7% reduction. The rendered output was pixel-identical. This is consistent with the 10–20% range cited in the glTF specification: the actual savings depend on how many textures are embedded and whether Draco compression is applied.

The smallest useful mental model is this: the smallest valid glTF JSON file contains an `asset` object with version `2.0`, for example `{ "asset": { "version": "2.0" } }`. That is enough to identify the file as glTF 2.0, even if it contains no meshes, nodes, or scenes yet. Real assets add buffers, bufferViews, accessors, meshes, nodes, scenes, materials, textures, and animations on top of that core object.

The smallest valid GLB wraps that same JSON in binary framing. A GLB must contain a 12-byte header, then at least one JSON chunk. The header stores the magic value for "glTF", the version number (2), and the total byte length of the file. The JSON chunk then contains the same glTF scene description, padded to 4-byte alignment. A BIN chunk is optional — it only appears when the asset actually has binary payload data to embed.

That is why search results for "minimal valid GLB bytes structure" often look lower-level than ordinary glTF examples: GLB is a container format, so even the smallest valid file has binary framing overhead before you get to the actual scene JSON.

The correct MIME type for `.glb` files is `model/gltf-binary`. The correct MIME type for `.gltf` files is `model/gltf+json`. Using the right MIME type helps browsers, CDNs, and asset pipelines handle the files consistently instead of treating them as generic binary downloads.

In practice, many static hosts still fall back to `application/octet-stream` for `.glb` if you do not configure them explicitly. That does not always break loading, but it can cause unnecessary download behavior, incorrect content-type reporting in diagnostics, and confusing cache rules. If you control the server, set the MIME types correctly.

Single-file delivery for web embedding: When uploading a 3D model to a web platform, CMS, e-commerce product page, or social media platform that accepts 3D content (like Facebook/Meta 3D posts, Shopify product pages, or Sketchfab), use GLB. All major platforms expect GLB as the upload format — they handle the hosting and delivery. A single `.glb` file is simpler to upload, track, and version.

AR experiences: Apple's AR Quick Look requires USDZ, while Android Scene Viewer and most web-based AR stacks commonly use GLB. If you are building a cross-platform AR workflow, GLB is usually the web/master asset and USDZ is the Apple-specific export you generate alongside it.

Web applications with Three.js, Babylon.js, or model-viewer: These libraries load GLB efficiently — the binary format maps directly to GPU data structures with minimal processing. The single-file nature simplifies HTTP caching (one cache entry per asset) and service worker handling.

Sharing and distribution: Email a GLB file to a client, and the model, materials, textures, and animations are all in one attachment. Send a glTF folder and the recipient needs to keep all files together. For any context where simplicity of distribution matters, GLB wins.

Production deployment: Web applications serving 3D models at scale benefit from GLB's single-file nature: one URL per asset, simpler CDN configuration, atomic invalidation (update one file instead of coordinating updates to JSON + BIN + multiple texture files).

Development and debugging workflows: glTF's human-readable JSON is invaluable when building or debugging 3D content pipelines. Open the `.gltf` file in any text editor and you can immediately inspect the scene structure: which materials are assigned to which meshes, what animation clip names are defined, how many nodes and textures the scene contains. With GLB, you need a specialized binary viewer to inspect the same information.

Iterative texture and material editing: When working on a model where textures change frequently, glTF's external file structure is a significant workflow advantage. You can update a texture image file without re-converting the entire model. The JSON references the texture by filename — just replace the file, reload the scene. With GLB, any texture change requires repacking the entire binary container.

Shared texture atlases: Multiple glTF models can reference the same external texture file. A scene with 10 objects that all use the same wood texture references one external `wood.jpg` rather than embedding 10 copies. Browsers cache the shared texture once. This is only possible with glTF external files, not GLB embedding.

When your pipeline already handles multiple assets: In a game engine or content pipeline that manages many 3D assets with a build system, the multi-file glTF structure integrates naturally with asset dependency graphs and incremental build systems. The JSON is easy to parse and modify programmatically.

Academic and research use: When documenting, teaching, or publishing 3D content for peer review, glTF's JSON transparency is an asset. Researchers can inspect and verify the model parameters without specialized tools.

Use these scenario-based recommendations to determine the best packaging variant for your situation.

Load time — single file vs. multiple requests: glTF with external files requires multiple HTTP requests (the JSON, then each referenced .bin and texture file, potentially in parallel). GLB makes a single HTTP request. For web applications, single HTTP requests are generally faster when files are not already cached, especially on high-latency connections.

Texture caching: This is the main counter-argument to GLB. External texture files in glTF can be cached independently by browsers. If 10 web pages all use the same `wood.jpg` texture, a browser downloads it once and caches it across all pages. With GLB where textures are embedded, each GLB file is cached as a single unit — the texture is embedded 10 times and downloaded with each model.

Draco compression applies equally to both: Draco compression compresses the geometry buffer, which is part of the binary chunk. Both GLB and glTF can use Draco — in glTF, the Draco-compressed data is in the external .bin file; in GLB, it is in the binary chunk. The compression ratios are identical.

A practical recommendation for large-scale deployments: Use GLB with Draco compression for the geometry, and link to externally hosted textures (referenced by URL in the JSON chunk inside the GLB) to balance the single-file advantage with browser texture caching. This advanced pattern requires server-side asset management but delivers optimal performance for content-heavy 3D applications.