WebXR, one concept at a time
Every page here takes a single WebXR or three.js concept, gives you a demo you can tune with real parameters, and then explains what is actually happening underneath. No headset needed — the demos are built to run on an ordinary desktop browser first, and switch to a real immersive session only when your device supports one.
- 15concepts
- 56tunable demos
- 3essays
- 2languages
Where to start
The pages do not have to be read in order, but three routes through them come up often enough to be worth naming. Each one starts with the page that establishes the vocabulary the others assume.
- You have not written any WebXR yet
Start with sessions, which is the negotiation every XR page has to go through, then read reference spaces before you place anything in the scene. Those two together are most of what stops a first attempt from working.
- You have a VR scene and the framerate is wrong
Stereo rendering explains where the per-view cost comes from. Foveated rendering and layers are the two ways of paying less of it, and both are easier to judge once you know what you are measuring.
- Your AR content does not sit in the room
Hit testing gives you a surface to place against. Plane detection and anchors are what keep the content there while the runtime keeps revising its map of the room underneath you.
Browse by area
Sessions and lifecycle
How a page asks the browser for an immersive session, and what it is allowed to assume once it has one.
WebXR sessions
How a page asks for an immersive session, and what a reference space actually anchors to.
Reference spaces
Where (0, 0, 0) actually is, and why the same coordinate lands in five different places.
Session visibility
Three states, not two. The middle one is where most implementations get it wrong.
Environment blend modes
Why the same scene vanishes on an additive display, and what black really means.
Rendering and presentation
What actually gets drawn, how many times, and who composites the result.
Input and movement
Controllers, hands, and the uncomfortable problem of moving someone through a space they are standing still in.
Understanding the real world
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.
AR hit testing
Finding real-world surfaces so virtual objects can sit on them.
Plane detection
Surfaces that appear, grow and merge — and why that changes how you attach content.
Anchors
Keeping placed content on a real point while the runtime rewrites its own map.
Depth sensing
Reading the device depth buffer, and the one comparison that makes AR sit in the room.
Lighting estimation
Spherical harmonics and a reflection cube map, so virtual objects belong to the room.
Essays
Longer pieces about where AI and XR meet, and what the seam between them actually costs.
The runtime gives you geometry, not meaning
Scene understanding is the obvious use for a vision model on a headset, and it is also where the web platform has drawn a line it does not intend to move.
9 min readThere is no typing indicator in a room
Conversational latency that a text interface absorbs invisibly becomes a performance problem the moment the speaker has a body.
10 min readWhat sits between a generated mesh and a WebXR scene
The generation step got fast. The steps on either side of it did not, and the gap between them is where the time actually goes.
10 min read
How these pages are written
Each page takes one concept and does three things with it: a demo you can tune with the parameters the real API exposes, an explanation of what the runtime is doing, and a list of the mistakes that cost the most time. The demos simulate the visible consequence rather than the mechanism, because a desktop browser cannot reproduce headset hardware and pretending otherwise would teach you the wrong thing.
The prose is server-rendered HTML. Turn JavaScript off and you lose the demo and keep the entire explanation, which is deliberate: a page whose content only exists inside a canvas is a page nobody can search, quote, or read on a slow connection.
Compatibility numbers are dated where they appear, because they expire. The specification and MDN will tell you what an interface is; these pages are about what happens when you get it subtly wrong, which is the part that costs an afternoon.