Khronos glTF Extension Prefixes Explained

This article explores the extension architecture of the glTF (GL Transmission Format) 3D standard, focusing on how extensions are categorized and standardized. It specifically identifies the official naming prefix assigned to Khronos-ratified extensions and outlines how these prefixes ensure interoperability, forward compatibility, and standardized feature adoption across different 3D rendering engines and authoring tools.

The official naming prefix that identifies Khronos-ratified extensions in glTF is KHR (written as KHR_ before the extension name).

Extensions carrying the KHR prefix represent the highest tier of standardization within the glTF ecosystem. These extensions have been formally reviewed, ratified, and published by the Khronos 3D Formats Working Group. Because they undergo rigorous cross-vendor scrutiny, KHR extensions are widely supported by major 3D software suites, runtime engines, and web viewers.

The glTF Extension Prefix Hierarchy

To prevent namespace collisions and clearly communicate the maturity and ownership of new capabilities, glTF enforces a structured prefixing system divided into three tiers:

  1. Khronos Ratified (KHR_): Features that have broad consensus and full approval from the Khronos Group. These frequently define core visual enhancements or significant structural capabilities (such as KHR_materials_unlit or KHR_texture_basisu).
  2. Multi-Vendor (EXT_): Extensions developed collaboratively by two or more independent vendors. These define features that multiple organizations agree on but have not yet undergone full Khronos ratification (such as EXT_meshopt_compression).
  3. Vendor-Specific (e.g., MSFT_, NV_, FB_): Extensions created by a single company or individual project to introduce specialized features tailored to specific pipelines, runtimes, or platforms.

How KHR Extensions Function in glTF

In a glTF asset (JSON or binary .glb), extensions are declared at the root level using the extensionsUsed and extensionsRequired arrays:

  • extensionsUsed: Informs the loader that the specified extension (for example, KHR_lights_punctual) is present in the file. A loader that does not understand the extension can still open the asset, ignoring the extension's additional data while rendering the fallback content.
  • extensionsRequired: Informs the loader that supporting the extension is mandatory to render or interpret the asset properly. If a parser does not recognize a required extension prefixed with KHR_, it must fail gracefully rather than display a corrupted scene.

By adhering to the KHR_ prefix convention, developers and 3D toolmakers maintain a predictable, reliable baseline for extending 3D asset capabilities across the industry.