All topics
Fifteen concepts, grouped into four sections that build on each other.
Each page on this site is one concept with a demo you can tune and a written explanation underneath. The four sections below are ordered: sessions establish the vocabulary, rendering covers what gets drawn, input covers how people act on it, and the real-world section covers everything the device has to work out about the room before any of it can be placed.
Sessions and lifecycle
4 pages
How a page asks the browser for an immersive session, and what it is allowed to assume once it has one.
Everything else on this site depends on this section. A WebXR page does not simply switch to 3D — it negotiates. It asks for a session of a particular mode, lists the features it needs, and waits for a user gesture and a permission decision. Only then does it get an XRSession, and only then do the other APIs mean anything.
Rendering and presentation
3 pages
What actually gets drawn, how many times, and who composites the result.
A headset frame is not a browser frame. Your scene is drawn once per view — two views for a stereo headset, sometimes more — into a framebuffer the runtime owns, at a cadence the runtime sets, and then a compositor you do not control decides what the user actually sees and when. Most performance surprises in WebXR come from not knowing where that boundary sits.
Input and movement
3 pages
Controllers, hands, and the uncomfortable problem of moving someone through a space they are standing still in.
Input in XR is not events. There is no click, no keydown, no element under the pointer. On every frame you are handed a set of input sources, each with a pose, a gamepad-like button state, and possibly a 25-joint hand skeleton — and it is your job to decide what any of that means. A pinch, a grab, a pointer ray, a teleport arc: none of them exist in the API. You build them from poses.
Understanding the real world
5 pages
Five ways a runtime tells your page something about the room the user is standing in — each with a different shape and a different lie.
This is the largest section on the site, and the one where the mental model matters most. In VR your scene is the whole truth. In AR it is a guest in a room the runtime is still figuring out, and every API here is a different answer to the same question: what does the device actually know about that room, and how much should you trust it?