What Defines the Binary GLB Container Header in glTF?

A binary glTF (GLB) file begins with a fixed 12-byte header that identifies the container format, specifies the specification version, and defines the total byte length of the entire file. Following this header, the file structure consists of structured binary chunks containing JSON-formatted scene metadata and raw binary buffers for meshes, animations, and textures. Understanding the exact byte layout, field definitions, and data alignment of this 12-byte header is essential for building GLB parsers, validators, and asset pipelines.

The 12-Byte Header Specification

The binary glTF header must occupy the exact first 12 bytes of any GLB container. All fields are encoded as 32-bit unsigned little-endian integers (uint32).

The header consists of three sequential fields:

1. magic (4 bytes): A constant byte sequence identifying the file as a GLB container. It represents the ASCII string glTF, which corresponds to the hexadecimal value 0x46546C67. When evaluated as a 32-bit little-endian integer, byte 0 is 0x67 ('g'), byte 1 is 0x6C ('l'), byte 2 is 0x54 ('T'), and byte 3 is 0x46 ('F').
2. version (4 bytes): An integer defining the binary container format version. For assets compliant with glTF 2.0, this value must evaluate to integer 2 (0x00000002).
3. length (4 bytes): The total size of the binary container in bytes, including the 12-byte header itself, all chunk headers, and all chunk payload data.

Binary Layout and Memory Alignment

The layout of the 12-byte header maps to a standard C/C++ struct:

struct GlbHeader {
    uint32_t magic;    // 0x46546C67 ("glTF")
    uint32_t version;  // 2 for glTF 2.0
    uint32_t length;   // Total file size in bytes
};

Validation Requirements for GLB Parsers

When developing an asset loader or parser, validating the header ensures file integrity before attempting to read subsequent data chunks:

• Magic Number Verification: Read the first four bytes and verify equality with 0x46546C67. If the value does not match, abort processing immediately, as the file is not a valid GLB container.
• Version Check: Inspect the version field. If an engine only supports glTF 2.0, ensure this value equals 2. If it equals 1, the asset belongs to the deprecated glTF 1.0 binary specification, which uses a different chunk framing system.
• Payload Bounds Checking: Compare the header's length field against the actual byte length reported by the file system or network transport buffer. A mismatch indicates an incomplete download or corrupted file.

Transition to the Chunk Stream

Directly following byte 11 of the 12-byte container header, the GLB format introduces chunked storage. Each chunk consists of an 8-byte chunk header (uint32 chunkLength and uint32 chunkType), immediately followed by the chunk payload.

The first chunk immediately following the 12-byte header must always be the structured JSON chunk (chunkType = 0x4E4F534A, representing "JSON"), containing the scene hierarchy, node definitions, and buffer views. Subsequent chunks contain the raw binary buffer data (chunkType = 0x004E4942, representing "BIN\0"). Proper parsing requires advancing precisely 12 bytes past the start of the file before reading the first chunk header.