How Are GLB Chunk Types Defined and Ordered?

A GLB container packages glTF 3D assets into a single binary stream composed of a 12-byte file header followed by sequentially packed data chunks. Each chunk consists of an 8-byte descriptor header—storing its byte length and a 4-byte ASCII type code—paired with a payload aligned to a 4-byte boundary. The glTF 2.0 specification enforces a strict sequence: a JSON metadata chunk must appear first, followed by an optional binary buffer chunk, alongside any application-defined extension chunks.

Anatomy of a GLB Chunk

Every chunk inside a GLB file follows an explicit 8-byte chunk header format before its data payload:

• chunkLength (uint32, 4 bytes): The exact length of the chunk data payload in bytes, excluding the 8-byte chunk header.
• chunkType (uint32, 4 bytes): A 32-bit integer representing an ASCII string that specifies the chunk's format and contents.
• chunkData (byte array): The payload corresponding to the specified chunk length.

To preserve memory alignment requirements for CPU and GPU processing, each chunk payload must be padded with trailing characters so that the entire chunk ends on a 4-byte boundary.

Chunk Types in glTF 2.0

The glTF 2.0 standard defines two primary chunk types:

1. Structured JSON Content (JSON):

• Hex Representation: 0x4E4F534A (ASCII characters 'J', 'S', 'O', 'N' in little-endian order)
• Description: Contains the core scene hierarchy, materials, node structures, mesh definitions, and accessor indices serialized as UTF-8 JSON text.
• Padding Requirement: If the byte length of the JSON string is not a multiple of 4, it must be padded with trailing space characters (ASCII 0x20).

2. Binary Buffer (BIN\0):

• Hex Representation: 0x004E4942 (ASCII characters 'B', 'I', 'N' followed by a null byte 0x00 in little-endian order)
• Description: Stores raw binary arrays containing vertex positions, normal vectors, texture coordinates, animation keyframes, skinning weights, and embedded image files.
• Padding Requirement: If the binary payload length is not divisible by 4, it must be padded with trailing null bytes (0x00).

Required Chunk Ordering

GLB parsers read chunks sequentially starting immediately after the initial 12-byte file header (magic, version, and length). The specification mandates strict ordering rules:

• First Chunk: Must always be the JSON chunk. Placing any other chunk type at the start of the chunk sequence constitutes an invalid GLB file.
• Second Chunk: If the asset references a binary buffer, the BIN\0 chunk must follow directly after the JSON chunk. Only one BIN\0 chunk is permitted per GLB container.
• Subsequent Chunks: Any additional vendor extensions or custom application chunks must follow after the BIN\0 chunk (or directly after the JSON chunk if no BIN\0 chunk exists). Unknown extension chunks should be safely skipped by standard parsers using the declared chunkLength.