Which JSON Schemas Validate a glTF File?

This article outlines the specific JSON schemas that validate the top-level structure of a standard glTF (GL Transmission Format) 2.0 asset. It identifies the root schema definitions provided by the Khronos Group, breaks down the core object arrays defined at the document root, and explains how validation tools utilize these draft schemas to ensure asset conformance.

The Root Schema: glTF.schema.json

In the official glTF specification maintained by the Khronos Group, validation begins at a single entry point: glTF.schema.json. This schema targets the document root of any .gltf manifest. It acts as the master orchestrator, importing dozens of sub-schemas via JSON Schema references ($ref) to validate every individual component.

The schema complies with JSON Schema Draft-04 or Draft-07 (depending on the exact minor release version of the schema repository) and enforces that the root of every valid glTF file must be a JSON object containing defined top-level properties.

Primary Top-Level Property Schemas

The root glTF.schema.json defines constraints for several high-level properties, each governed by its own dedicated schema file:

  • Asset Metadata (asset.schema.json): Validates the mandatory asset object. It strictly requires the version string (typically "2.0") and optionally checks metadata properties like generator, copyright, and minVersion.
  • Scene Graph Structure (scene.schema.json and node.schema.json): Validates the scenes array, the active scene index pointer, and the nodes array. Nodes describe transformations, child hierarchies, and attachments to cameras, meshes, or skins.
  • Geometry and Primitives (mesh.schema.json and mesh.primitive.schema.json): Checks the meshes array, ensuring that mesh primitives point to valid attribute accessor indices and material indices.
  • Buffer Management (buffer.schema.json and bufferView.schema.json): Defines the buffers (raw binary data sources) and bufferViews (contiguous slices of binary data), validating byte offsets, byte lengths, and target buffer types.
  • Binary Accessors (accessor.schema.json): Validates the accessors array, which provides data types (such as VEC3 or SCALAR) and component types (such as FLOAT or UNSIGNED_SHORT) for interpreting binary data from buffer views.
  • Materials and Textures (material.schema.json, texture.schema.json, sampler.schema.json, image.schema.json): Validates visual surfaces, including PBR metallic-roughness models, texture wrapping modes, and image references.
  • Animations and Skins (animation.schema.json and skin.schema.json): Governs skeletal rigging hierarchies and keyframe channel bindings.
  • Cameras (camera.schema.json): Validates perspective and orthographic projection parameters.

Extensions and Custom Metadata

Two additional schemas govern custom data at the root level:

  • extension.schema.json: Validates the extensions dictionary used for Khronos-approved (KHR_), vendor (MSFT_, EXT_), or engine-specific modifications. The root schema also enforces the arrays extensionsUsed and extensionsRequired as string lists.
  • extras.schema.json: Validates the application-specific extras field, which permits any valid JSON value for custom metadata without violating format compliance.

Standard validation suites, such as the Khronos glTF Validator, compile these schemas alongside semantic validation passes to ensure that indices point to actual entries within the top-level arrays.