Global technology/business coverage. Sources checked 13 October 2026.

A product team commissioning a three-dimensional viewer should distinguish the asset delivered to the viewer from the editable project used to create it. glTF 2.0 helps frame that distinction. A runtime delivery file can be a useful outcome without preserving every feature of the authoring environment. Agreeing what the handoff must accomplish is more useful than assuming a familiar file extension settles the entire workflow.

Khronos defines a delivery purpose

The Khronos glTF 2.0 specification describes an API-neutral runtime asset delivery format connecting content creation tools with graphics applications. Its introduction addresses both exporters and applications loading the asset. The rendered specification is labelled version 2.0.1, dated 11 October 2021. This establishes the document’s stated scope; it does not demonstrate how an individual commercial viewer handles a supplied asset.

Write two deliverables when you need two

If future editing matters, specify an editable master separately from the runtime package. Describe who will maintain each, what application and version the master requires, and which changes a later owner expects to make. These are proposed handoff questions, not claims about a particular supplier’s contract. A team can then evaluate the two deliverables on their own purposes instead of discovering after delivery that the runtime file was mistaken for a complete source project.

For a hypothetical product viewer, the runtime acceptance task could concern the selected product’s appearance and interaction in the actual target application. The master acceptance task could concern whether a qualified editor can make an agreed change in the specified authoring environment. Passing one does not establish the other. Keep the outcomes labelled so that a successful viewer demonstration is not reported as proof of unlimited future editability.

Interoperability requires a named destination

A format intended for interchange does not remove every difference between implementations. Name the destination viewer, its version and the features the product experience requires. If the exported asset uses an extension, determine whether the actual destination supports it. This article has not checked a specific viewer or extension combination, so it does not promise uniform rendering across browsers, devices or applications.

Also distinguish a visually acceptable result from a technically complete transfer. A viewer might show the part of an asset important for a demonstration while the handoff has other requirements that remain unexamined. A useful acceptance note records the chosen inputs and the exact observation. Avoid moving from “loaded in this application” to “works everywhere” without the broader evidence that such a statement would require.

Make the business question measurable

For a commissioning team, the useful question is whether a specific deliverable supports a specific customer-facing task. Decide in advance what needs to be observed and what would lead to a revision request. Do not attach a conversion-lift percentage or a customer-satisfaction claim to the format itself. Those would require their own study of the product experience, audience and conditions, none of which was performed here.

glTF’s documented delivery focus can improve the clarity of a brief. It lets the team request a bounded runtime asset while preserving a separate conversation about source ownership and later editing. The conclusion is a better-defined handoff, not an endorsement of a supplier, a compatibility certification or evidence that a viewer will improve sales.

Sources and scope

• Khronos glTF2.0 specification — Rendered documentversion2.0.1,2021-10-11; introduction checked2026-10-13

Format-scope analysis only. No export, validator, browser viewer, rendering or ecommerce conversion test was run; specific extension and runtime support need their own checks.

Related coverage: Technology archive.