How Does GLB Differ Mechanically From glTF?

This article examines the structural, architectural, and operational differences between standard glTF and its binary counterpart, GLB. While both formats are governed by the Khronos Group specification to transmit 3D scenes efficiently over the web, glTF functions as a multi-file, text-based manifest referencing external assets, whereas GLB packages the entire scene graph, raw vertex data, and image textures into a single, byte-aligned binary container. The sections below break down file structures, memory layout, runtime loading mechanics, and common production tradeoffs.

Architecture and File Composition

The primary difference between glTF (GL Transmission Format) and GLB lies in how each format organizes scene assets on disk and across the network.

Standard glTF separates a 3D asset into distinct pieces:

Standard glTF can embed binary buffers and images directly into its JSON structure via base64 data URIs. However, base64 encoding incurs a roughly 33% file size penalty and adds significant string-parsing overhead on the CPU during decode time.

In contrast, GLB (Binary glTF) compresses the entire model into a single self-contained binary file ending in .glb. It encapsulates the JSON scene description, binary buffers, and texture images into contiguous chunks within one binary stream, eliminating external file dependencies without base64 overhead.

Binary Layout and Chunk Specifications

GLB solves the fragmentation of standard glTF through a strict, little-endian binary framing layout. A compliant GLB file consists of a 12-byte header followed by two or more structured binary chunks.

The 12-Byte Header

The file begins with a fixed header that runtime loaders parse to validate the stream:

Chunk Structure

Every chunk following the header follows a uniform layout:

GLB specifies two standardized primary chunk types:

  1. JSON Chunk (0x4E4F534A / "JSON"): This must be the very first chunk after the 12-byte header. It contains UTF-8 text representing the standard glTF JSON hierarchy. To maintain proper memory alignment for subsequent operations, the JSON payload must be padded with trailing ASCII space characters (0x20) to satisfy 4-byte boundary alignment.
  2. Binary Buffer Chunk (0x004E4942 / "BIN\0"): If present, this chunk directly follows the JSON chunk. It stores all geometry accessors, vertex attributes, skinning matrices, animation splines, and embedded texture images. The binary chunk payload is padded with trailing zero bytes (0x00) to align with a 4-byte boundary.

Buffer Referencing and Memory Mapping

Standard glTF references external binary assets via relative URIs inside the buffers array:

"buffers": [
  {
    "uri": "model_data.bin",
    "byteLength": 24576
  }
]

When a loader parses this glTF block, it must issue a secondary network fetch to retrieve model_data.bin.

In a GLB container, the binary chunk behaves as buffer index 0. In the embedded JSON chunk, the buffer entry omits the uri property entirely:

"buffers": [
  {
    "byteLength": 24576
  }
]

Because byte offset zero in the binary chunk corresponds to the start of this implicit buffer, runtime engines can point GPU buffer views directly into the loaded memory segment. Using typed arrays in web environments (such as JavaScript's ArrayBuffer and DataView), loaders can extract sub-buffers for vertex arrays without copying or base64 decoding.

Embedded Textures via BufferViews

Standard glTF references textures using the uri property inside the images object, pointing to separate local files or web URLs.

In GLB, textures are embedded directly within the single binary chunk. The JSON chunk maps each image using a bufferView reference and an explicit MIME type instead of a URI:

"images": [
  {
    "bufferView": 2,
    "mimeType": "image/png"
  }
]

The runtime parser locates the image's raw byte stream by querying the start offset and byte length defined in the corresponding bufferView, then passes those bytes to an image decoder or WebGL/WebGPU texture upload routine.

Runtime and Transmission Characteristics

The structural differences between glTF and GLB translate to distinct performance characteristics during deployment:

Network Behavior

Standard glTF requires multiple HTTP/HTTPS requests to download the JSON manifest, vertex buffers, and texture files. While HTTP/2 multiplexing mitigates connection latency, multi-file delivery still introduces synchronization hurdles where rendering must pause until critical binary buffers arrive. GLB requires only one network request, making asset streaming predictable and reducing network request overhead.

CPU and Memory Overhead

Unbundled glTF with base64 data URIs demands high CPU usage because strings must be decoded into byte arrays in client memory. GLB eliminates this step completely. Because the binary chunk is already structured to match native memory alignment, graphics engines can upload geometry buffers directly from the downloaded file payload into GPU VRAM with minimal parsing delay.

Version Control and Authoring

Separate glTF files offer superior workflows during development. The JSON manifest can be inspected in text editors, checked into Git repositories with readable diffs, and updated without touching large binary geometry files. GLB files are opaque binary blobs that are unsuitable for text-based version control or manual parameter edits.

Standard glTF is optimized for asset development and pipeline flexibility, whereas GLB is engineered for fast, atomic runtime distribution.