The WebXR Device API Specification Repository: What immersive-web/webxr Actually Contains
Repository for the WebXR Device API Specification.
At a glance
- What is it?
- This repository is the Bikeshed source for the W3C WebXR Device API specification, not a browser library or a downloadable runtime. It is for people who need to read, cite or edit the normative definition of the API.
- Who is it for?
- Adopt this repository if you are implementing WebXR in a browser engine, reviewing a normative change, or need to cite the specification's exact wording; the README points contributors at the issues list and the proposals repository before any pull request. Do not adopt it expecting an installable WebXR runtime, a download, or a polyfill: the repository holds index.bs, the explainers, and the legacy WebVR migration document, and nothing that executes in a page.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Bikeshed, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the webxr repository is, and what it is not
The WebXR Device API is described in the README as an API for accessing virtual reality and augmented reality devices, including sensors and head-mounted displays on the Web. The repository itself is the specification's source of truth, not an implementation of it. Its top level holds index.bs, the Bikeshed document from which the published specification is generated, alongside explainer.md, input-explainer.md, privacy-security-explainer.md, spatial-tracking-explainer.md, accessibility-considerations-explainer.md and webvr-migration.md. The README also carries a table mapping the API's reach across two axes: headset devices and handheld devices such as a phone, crossed with VR and AR. VR on a headset is the successor to WebVR; VR on a phone is the magic window behaviour; AR on a headset is mixed reality headsets; AR on a phone is phone AR. That table is the clearest statement in the README of the scope the specification is written to cover. If you arrived looking for a webxr download, a browser build, or a JavaScript package, this is the wrong artefact. It contains no runtime code to load in a page.
Who needs the specification source rather than the published page
Most developers should read the published specification at immersive-web.github.io/webxr/, which the README lists as the primary link, and then consult MDN, which the README links as WebXR on MDN. The repository matters to a narrower group. Browser engineers implementing the API need the Bikeshed source because diffs against index.bs are how normative changes are reviewed. People writing a specification-adjacent proposal need the explainers, since the README lists an explainer, an input explainer, a privacy and security explainer and a spatial tracking explainer as separate documents. Anyone arguing about what the API requires in a particular case needs the source text rather than a summary. The README also points to the Immersive Web Working Group and the Immersive Web Community Group, the public-immersive-web mailing list, and the bi-weekly call minutes, so the repository is the entry point to a standardisation process rather than a product.
Building index.html from index.bs with make
The README's Maintainers section gives a single instruction for generating the specification document from the Bikeshed source. There is no package manager step documented, no npm install, and no published build artefact to fetch. The command is:
makeRunning it in the repository root is documented as producing index.html from index.bs. Bikeshed is the tool named in the README's link list, and the README treats the generated index.html as the build output. If you want a first real use, treat this as a documentation build rather than a program: clone the repository, run make, and open the generated index.html to read the specification with the same structure the editors work against. Expect the build to depend on the Bikeshed toolchain being available on your machine, because the README documents the command but not the toolchain setup around it. That gap is the first thing a new contributor will hit.
The web-platform-tests expectation for normative changes
The README's Tests section states that for normative changes a corresponding web-platform-tests pull request is highly appreciated, and that typically both pull requests are merged at the same time. It adds a sequencing rule: a test change that contradicts the specification should not be merged before the corresponding specification change. When testing is not practical, the README asks contributors to explain why and, if appropriate, to file a web-platform-tests issue to follow up later, using the type:untestable or type:missing-coverage label as appropriate. This is a real constraint on contribution cost. A wording fix in index.bs may be cheap, but a behavioural change drags a second repository into the pull request, and the merge ordering is not left to the contributor's judgement. The README does not document rollback, so there is no guidance in the repository on reverting a merged normative change.
Why this is not the way to add WebXR to Chrome, Firefox or a Quest headset
People search for how to enable WebXR in Chrome, how to use WebXR on a Quest 2 or Quest 3, and for a webxr compatible browser. This repository answers none of those directly. It defines the API; it does not ship the implementation, and the README names no browser flag, no chrome:// URL, no settings page and no device-specific setup step. The README does list a Legacy WebVR API specification and a Legacy Gamepad Extensions API specification, and states that development of the WebVR API has halted in favour of being replaced by the WebXR Device API, with several browsers continuing to support the older version in the meantime. That sentence is the whole of the migration story in the README, and it is complemented by webvr-migration.md in the repository root. If your question is about turning the API on in a particular browser on a particular headset, the specification repository is the wrong place to look, and the README does not pretend otherwise.
Where the specification stops and the module repositories begin
The README's link list is long, and it is the best map of the project's boundaries. Beyond the main specification it names a gamepads module, an AR module, DOM overlays, hit test, WebXR input profiles, layers, hands input, anchors, computer vision, geo alignment, lighting estimation, navigation, performance improvements, real-world geometry, spatial favicons, depth sensing, and a WebXR WebGPU binding. Each of those is a separate repository. This matters when you are deciding where a change belongs: the main repository is not a catch-all. The README also links a page listing all specifications with detailed status in the Working Group and Community Group, which is the place to check whether a feature you care about lives in the core API or in a module. A feature request filed against the wrong repository will be redirected, and the README's Taking Part section asks contributors to check the issues list and the proposals repository before adding to the discussion.
Licence, maintenance and the cost of tracking the specification
The README quotes LICENSE.md: all documents in the repository are licensed by contributors under the W3C Software and Document License. That is a document licence rather than a code licence, which is consistent with a repository whose main artefact is a specification. The repository's GitHub metadata reports the licence as NOASSERTION, so tooling that classifies licences automatically will not resolve it; read LICENSE.md and the W3C licence text rather than trusting a badge. This is not legal advice, and anyone redistributing the specification text should read the licence themselves. On maintenance, the last push to the default branch was on 2026-09-10 and the repository is not archived. The only release listed is CRS-20220331, dated 2022-04-01. The gap between a 2022 candidate release snapshot and a 2026 push is normal for a living specification: work continues in the source document while tagged snapshots are rare. The upgrade cost of following this repository is therefore not a version bump. It is re-reading index.bs, because the text is the interface and it changes without a release number to announce it.
Editorial conclusion
Adopt this repository if you are implementing WebXR in a browser engine, reviewing a normative change, or need to cite the specification's exact wording; the README points contributors at the issues list and the proposals repository before any pull request. Do not adopt it expecting an installable WebXR runtime, a download, or a polyfill: the repository holds index.bs, the explainers, and the legacy WebVR migration document, and nothing that executes in a page. Verify first that the change you want belongs in the main specification rather than in one of the module repositories the README links, and check the web-platform-tests guidance in the README before opening a pull request, because the README states that for normative changes a corresponding web-platform-tests pull request is expected and that both are typically merged at the same time.
Frequently asked questions
What is the WebXR Device API used for?
The README describes it as an API for accessing virtual reality and augmented reality devices, including sensors and head-mounted displays on the Web. Its table covers VR on headsets, VR on phones as magic window behaviour, AR on mixed reality headsets, and AR on phones.
How do I install WebXR from this repository?
You do not install it. The repository holds the Bikeshed source for the specification, and the README's only build instruction is the make command that generates index.html from index.bs. There is no package to install and no runtime in the repository.
Is WebXR better than native XR?
The README does not compare WebXR with native XR platforms, so the repository cannot answer this. What it does state is that the WebVR API's development halted in favour of being replaced by the WebXR Device API, with several browsers continuing to support the older version in the meantime.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/immersive-web-webxr)