glTF vs GLB — Same Format, Different Packaging

Same Data, Different File Layout

glTF 2.0 (Khronos Group, 2017) is the schema. .gltf stores the schema as JSON with separate .bin geometry buffers and image files referenced by URI. .glb packs the same JSON, buffers, and images into a single binary container. Loaders parse both — three.js, Babylon.js, model-viewer, Blender, Unity, Unreal all handle either. The on-screen result is identical; the choice is about delivery, not capability.

How GLB Wraps glTF Internally

A GLB file starts with a 12-byte header — magic number 'glTF' (4 bytes), version 2 (4 bytes), total file length (4 bytes). Then come length-prefixed chunks. Chunk 0: JSON (the same JSON that would be in .gltf, padded to 4-byte alignment). Chunk 1: BIN (concatenated buffer data — vertices, indices, UVs, normals, animations). Optional Chunk 2+: embedded image data. The JSON references buffer chunk 1 via byteOffset/byteLength, so loaders parse JSON first, then slice the binary chunk by offset. No ZIP, no compression, just length-prefixed binary.

Practical Differences

• File count — .gltf is 3+ files (JSON, .bin, textures); .glb is one file. One file means one HTTP request and no broken sub-asset references.
• Editability — .gltf JSON is human-readable and hand-editable; .glb requires extraction tools to inspect or modify.
• Size — .glb is slightly smaller (no JSON whitespace, no path overhead) but not compressed; for real size reduction use Draco or Meshopt.
• CDN delivery — .glb is friendlier (one Content-Type, one cache entry); .gltf needs CORS configured for sub-asset fetches.
• Streaming — .glb supports progressive load via byte-range requests; .gltf can stream sub-assets in parallel.
• Tooling — gltf-pipeline (Cesium) and gltf-transform (donmccurdy) convert between formats and apply Draco/Meshopt/KTX2 compression to either.

Which Should You Pick — Five Decision Rules

1. Open pcbviewer.app — for production web delivery, use .glb. One request, one Content-Type, one CDN entry, no broken references.
2. For development and debugging, use .gltf. JSON is readable in any text editor; you can hand-edit materials, swap textures, or inspect node hierarchy without tooling.
3. For asset libraries with shared textures across multiple models, use .gltf. Sharing a single PNG between five models saves bytes and CDN cache space.
4. For email or single-file handoff, use .glb. No risk of separating the package; one attachment is everything.
5. For maximum compression, apply Draco (KHR_draco_mesh_compression) and KTX2 (KHR_texture_basisu) regardless of container — both work in .gltf or .glb.

Why the Format Choice Affects Your Pipeline

Your CI/CD, CDN config, and asset versioning all depend on this. Multi-file .gltf needs CORS configured for each sub-asset domain, complicates cache busting, and risks broken links if a texture file gets renamed. Single-file .glb is easier to deploy but harder to debug. Pick based on your team's bottleneck — if asset debugging is the pain, .gltf during development; if CDN reliability is the pain, always .glb.

Where Each Format Wins

• E-commerce 3D — .glb for product viewers, simpler CDN integration
• AR/VR experiences — .glb for transport over network, model-viewer and WebXR both prefer it
• Game asset pipelines — .gltf during development with Draco compression at build time
• Architectural visualization — .glb for client previews, .gltf when sharing source assets
• Educational and museum 3D — .glb for embedding, .gltf for downloads when learners want to inspect the data

Verify Your Conversions in the Browser

Both .gltf and .glb may contain proprietary 3D models. MakerSuite 3D parses both formats entirely in your browser using three.js's GLTFLoader — no server, no upload, no cached copy. Drop your converted asset to verify geometry, materials, and textures before deployment. Safe for NDA work, prerelease product visualization, and IP-sensitive 3D models.