WebXR: VR and AR Games in the Browser
In This Guide
What Is WebXR and Why It Matters for Games
WebXR is the W3C standard API that gives web applications access to VR headsets, AR devices, and spatial tracking hardware through the browser. It replaced the older WebVR specification in 2019 and has matured into a stable, well-supported platform for building immersive content. The name itself captures the scope: the "XR" stands for extended reality, covering both virtual reality where the player is fully immersed in a synthetic environment and augmented reality where digital objects are layered onto the real world.
For game developers, WebXR solves a distribution problem that has plagued VR and AR since the beginning. Traditional VR games require players to find your title in a headset-specific app store, download a multi-gigabyte binary, and hope that the game supports their particular hardware. WebXR games are just web pages. A player can click a link on social media, enter VR mode in their browser, and be playing your game within seconds. There is no install friction, no app store approval process, and no platform-specific build to maintain.
The API itself handles the low-level communication between your JavaScript code and the XR hardware. It manages the render loop at the headset's native refresh rate (typically 72Hz, 90Hz, or 120Hz depending on the device), provides tracking data for the headset position and orientation, reports controller button states and hand joint positions, and handles the stereoscopic rendering pipeline that produces the left-eye and right-eye views. Your game code receives a callback each frame with all of this data, renders the scene using WebGL or WebGPU, and submits the frame back to the compositor.
What makes WebXR particularly compelling for game developers in 2026 is the reach. Chrome, Edge, Samsung Internet, Opera, and the Meta Quest Browser all support the core specification. Safari joined in with visionOS 2, bringing Apple Vision Pro into the WebXR ecosystem with full gaze-and-pinch input. The Interop 2026 initiative has made WebXR a focus area, meaning browser vendors are actively coordinating to close the remaining compatibility gaps between implementations. This is a technology moving from experimental to reliable.
VR vs AR on the Web
WebXR supports two primary session types that determine how your game interacts with the player's environment. Understanding the distinction is essential for choosing the right approach for your game concept.
An immersive-vr session takes over the player's entire visual field. The browser hands control of the display to your application, and the player sees only what your game renders. This is the session type for fully virtual worlds, space combat games, dungeon crawlers, puzzle rooms, and any experience where you want complete control over what the player sees. VR sessions work on dedicated headsets like the Meta Quest 3, PC-tethered headsets connected through SteamVR, and the Apple Vision Pro in its full immersion mode.
An immersive-ar session blends your rendered content with the real world. The player sees their actual surroundings through the headset's passthrough cameras (on devices like the Quest 3) or through transparent displays (on devices like the Apple Vision Pro or AR glasses), and your game objects appear anchored in physical space. AR sessions unlock capabilities like hit testing against real surfaces, plane detection for floors and tables, and spatial anchors that persist between sessions. AR games can use the player's living room as the game board, place virtual creatures on their kitchen table, or turn their entire house into a game level.
There is also the inline session type, which renders XR content in a standard 2D browser window without requiring a headset. This is useful for giving players a flat-screen preview of your 3D environment before they commit to putting on a headset, or for building games that work in both flat and immersive modes. Many WebXR games use inline sessions as a "magic window" fallback on phones, where tilting the device changes the view angle into the 3D scene.
A well-designed WebXR game often supports all three modes. The player browses your game page on their phone (inline mode), sees the 3D environment through a viewport they can tilt around, then picks up their Quest headset and enters the full VR experience. The same codebase, the same assets, the same game logic, just different ways of experiencing it.
Choosing a WebXR Framework
You technically can build a WebXR game using the raw WebXR Device API and plain WebGL, but very few developers choose this path. The API provides tracking data and frame timing, but rendering a scene, loading models, handling physics, and managing audio all require additional tooling. The practical question is which framework to build on.
Babylon.js treats WebXR as a first-class feature. Its WebXR Experience Helper handles session creation, controller mapping, teleportation, hand tracking, and the render loop automatically. You can get a working VR scene with a few lines of code: create a scene, call createDefaultXRExperienceAsync(), and your scene is now explorable in VR with full controller support. Babylon.js also includes built-in physics (Havok integration), audio management, particle systems, and a complete animation system. For developers who want a batteries-included approach to WebXR, Babylon.js is the strongest choice. Our Babylon.js WebXR guide covers the specifics.
Three.js supports WebXR through its VRButton and ARButton helpers and the WebGLRenderer's XR subsystem. The integration is solid but more manual than Babylon.js. You set up the XR session, configure the reference space, and handle controller events yourself using Three.js's event system. Three.js gives you more architectural freedom: pick your own physics engine, bring your own audio system, structure your game loop however you want. If you already know Three.js well or need fine-grained control over every aspect of your VR rendering pipeline, it is an excellent choice. See our Three.js WebXR guide for a step-by-step walkthrough.
A-Frame takes a declarative, HTML-based approach to WebXR. You describe your VR scene using custom HTML elements like <a-scene>, <a-entity>, and <a-box>, and A-Frame handles the WebXR session management, rendering, and input. It is built on top of Three.js, so you can drop down to Three.js code when the HTML abstraction is not enough. A-Frame is popular for prototyping and educational projects, though production games typically outgrow its declarative model and either move to Three.js directly or switch to Babylon.js.
PlayCanvas offers a visual editor similar to Unity or Unreal combined with a WebXR-capable runtime. It is particularly strong for teams that include non-programmers who need to position objects, tweak materials, and test VR scenes visually. The editor runs in the browser, making collaboration straightforward.
The framework choice depends on your priorities. Babylon.js for the fastest path to production WebXR with the most built-in features, Three.js for maximum flexibility and control, A-Frame for rapid prototyping, and PlayCanvas for teams that want a visual editor. All four produce standard WebXR content that runs on the same browsers and devices.
The WebXR Development Workflow
Building WebXR games follows a workflow that looks familiar to web developers but includes some VR-specific considerations that trip up newcomers.
Local development requires HTTPS. The WebXR Device API is only available in secure contexts, meaning your development server must serve pages over HTTPS even on localhost. Most frameworks provide development servers with self-signed certificates, or you can use tools like mkcert to generate locally trusted certificates. This is a hard requirement from browsers, not a framework limitation.
Testing without a headset is possible using browser extensions like the WebXR Emulator. This Chrome extension simulates a VR headset and controllers, letting you test your WebXR code on a desktop without plugging in hardware. The emulator supports head tracking simulation via mouse, controller position via keyboard shortcuts, and basic input event generation. It is not a substitute for real headset testing, but it eliminates the need to put on a headset every time you change a line of code.
On-device testing is essential before shipping. The performance characteristics of a Meta Quest 3 are very different from a desktop browser, and controller ergonomics only make sense when you are physically holding the controllers. Connect your headset to your development machine, navigate to your local HTTPS server's IP address, and test in the actual VR environment. For Quest devices, you can use adb to forward ports and access localhost directly.
Asset preparation for WebXR games favors glTF format for 3D models. The glTF specification is designed for real-time rendering and is supported natively by all major WebXR frameworks. Keep polygon counts reasonable (under 100,000 for mobile headsets), use texture atlasing to reduce draw calls, and consider using Draco or meshopt compression to shrink file sizes. The lighter your assets, the faster your game loads, and load time is critical when players expect to click a link and be playing immediately.
Deployment is identical to deploying any web application. Upload your files to a web server or CDN, ensure HTTPS is configured, and share the URL. No app store review, no platform-specific packaging, no waiting for approval. You update the files on your server and every player gets the new version on their next visit.
Controllers, Hands, and Input
Input handling is where WebXR games diverge most significantly from traditional web games. Instead of mouse clicks and keyboard presses, you are working with 6DoF (six degrees of freedom) tracked controllers, hand tracking with 25 joints per hand, and gaze-based input on some devices.
WebXR provides input through the XRInputSource interface. Each input source has a handedness (left, right, or none), a target ray that indicates where the controller is pointing, a grip space that represents the physical position of the controller in the player's hand, and a gamepad object with button and axis states. The most common controller layout includes a trigger (index finger), a grip button (middle finger squeeze), a thumbstick, and two face buttons, though the exact layout varies by hardware.
Hand tracking became a WebXR module in its own right, and devices like the Meta Quest 3 and Apple Vision Pro support it natively. When hand tracking is active, you receive 25 joint positions per hand at each frame, covering every finger joint from the wrist to the fingertips. You can detect pinch gestures, fist closures, pointing directions, and custom hand poses. Building hand-tracked interactions is more complex than controller-based input but creates a more natural, immersive experience.
The Apple Vision Pro introduced a gaze-and-pinch input model that is unique in the WebXR ecosystem. The player looks at an object (gaze targeting) and pinches their fingers together (pinch to select). This is fundamentally different from ray-pointer input and requires designing UI elements that are comfortable to look at and large enough to target with eye gaze. Our controller and hands guide covers implementation details for all input methods.
A robust WebXR game should detect which input sources are available at runtime and adapt. If controllers are connected, use ray-based pointing and trigger-to-select. If hands are tracked, switch to pinch gestures and direct manipulation. If only gaze is available, use gaze-and-dwell or gaze-and-pinch patterns. Feature detection is not optional in WebXR, it is how you reach the widest audience.
Browser and Device Support
The WebXR device support landscape in 2026 has reached a tipping point. Every major VR and AR platform now has at least basic WebXR support, though the depth of feature coverage varies significantly between devices.
Meta Quest (2, 3, 3S, Pro) offers the broadest WebXR support of any device family. The Quest Browser supports immersive-vr, immersive-ar with passthrough, hand tracking, controller input, plane detection, spatial anchors, hit testing, and depth sensing. The Quest 3 in particular has strong enough hardware to run graphically rich WebXR games at 90Hz. This is the primary development target for most WebXR game developers.
Apple Vision Pro joined the WebXR ecosystem with visionOS 2. Safari on visionOS supports immersive-vr and immersive-ar sessions with the gaze-and-pinch input model. The device's high resolution displays (23 million pixels across both eyes) make WebXR content look exceptionally sharp, but the renderer must handle this pixel count efficiently. Hand tracking works through the WebXR hand input module.
Desktop VR (SteamVR, WMR) works through Chrome and Edge on Windows. Any PC-tethered headset that supports OpenXR (Valve Index, HP Reverb, various WMR headsets) can run WebXR content through the desktop browser. Performance depends on the PC's GPU, giving you access to much more rendering power than standalone headsets.
Android phones support WebXR in Chrome for basic immersive-ar sessions using ARCore. This gives you surface detection and hit testing on hundreds of millions of Android devices. The experience is "magic window" style, where the phone screen shows the camera feed with your 3D objects overlaid.
iOS (iPhone and iPad) remains the largest gap in WebXR support. Safari on iOS does not support the WebXR Device API, and Apple has shown no indication of adding it. This means roughly half of mobile users cannot access WebXR content at all. Workarounds include using the inline session type for a flat 3D experience or directing iOS users to a non-XR version of your game. Our device support guide tracks the current state across all platforms.
Performance for Immersive Experiences
Performance in WebXR is not a nice-to-have, it is a medical necessity. When a VR game drops below its target frame rate, the player does not just see stuttering. They feel physically ill. The human vestibular system expects visual motion to match head movement perfectly, and when frames are dropped, the mismatch triggers motion sickness. This makes performance optimization more critical in WebXR than in any other type of web development.
The target frame rate depends on the device. The Meta Quest 3 defaults to 90Hz, the Apple Vision Pro runs at 90Hz, and PC-tethered headsets often target 90Hz or 120Hz. Your game must render two views (left eye and right eye) at these rates consistently. That means you have roughly 11 milliseconds per frame at 90Hz to run your game logic, update physics, process input, and render the scene twice.
The single most impactful optimization is reducing draw calls. Every material, every mesh, every texture swap is a draw call that costs CPU time on the JavaScript side and GPU time for the state change. Merge meshes that share materials, use texture atlases, implement instanced rendering for repeated objects (trees, rocks, bullets), and batch your geometry aggressively. A well-optimized WebXR game on the Quest 3 should stay under 100 draw calls for the main scene.
Level of detail (LOD) systems matter more in VR than in flat games because the player can look in any direction at any time. Distant objects should use simplified meshes and lower-resolution textures. Most WebXR frameworks support automatic LOD switching based on distance from the camera.
Shader complexity must be kept in check on mobile headsets. The Quest 3's Adreno 740 GPU is capable but not comparable to a desktop GPU. Avoid complex fragment shaders with multiple texture lookups, heavy lighting calculations, or screen-space effects. Baked lighting, simple PBR materials, and vertex-based effects perform much better on mobile VR hardware.
Our WebXR performance guide goes deep on profiling tools, GPU optimization techniques, and the specific bottlenecks you will encounter on each device class.
AR Capabilities on the Web
WebXR's AR capabilities extend well beyond simply rendering 3D objects over a camera feed. The specification includes several modules that give your game awareness of the physical environment.
Hit testing lets you cast a ray into the real world and find where it intersects with physical surfaces. This is how you place a virtual chess board on the player's actual table, or position a portal on their floor. Hit testing works on both the Quest 3 (using depth cameras) and Android phones (using ARCore).
Plane detection identifies flat surfaces in the player's environment, classifying them as floors, walls, tables, or ceilings. Your game can use detected planes as collision surfaces for physics, as spawn points for game objects, or as boundaries for the play area. The Quest 3's plane detection is particularly robust, identifying surfaces in real-time as the player moves through their space.
Anchors allow you to pin virtual objects to specific locations in the physical world. An anchor persists its position even as the tracking system refines its understanding of the environment, preventing your game objects from drifting. Persistent anchors survive across sessions, so a player can leave a virtual trophy on their shelf and find it there the next time they launch your game.
Depth sensing provides a depth map of the physical environment, enabling realistic occlusion where real objects properly hide virtual objects behind them. Without depth sensing, virtual objects always render on top of the real world, breaking the illusion. With it, a virtual ball can roll behind a real couch and disappear from view naturally.
These capabilities open up game genres that simply are not possible in pure VR. Room-scale AR games that turn the player's house into a dungeon, tabletop strategy games that play out on a real table, fitness games that use actual floor space for movement, and location-based games that react to the player's physical surroundings. Our AR games guide covers each module with code examples.
Is WebXR Production Ready?
This is the question every developer asks before committing to WebXR, and the honest answer is nuanced. WebXR is production ready for certain types of games and experiences, but it comes with real limitations that you need to understand upfront.
What works well: casual VR games, social experiences, educational content, product configurators, virtual tours, puzzle games, and any experience where the visual fidelity requirements are moderate and the interaction model is straightforward. The Moon Rider music game, Hubs social platform, and numerous WebXR demos have proven that engaging, polished VR experiences can run entirely in the browser.
What is challenging: graphically demanding games that push hardware limits, games requiring deep platform integration (achievements, friends lists, cloud saves), competitive multiplayer games where input latency matters at the millisecond level, and games targeting iOS users. The browser adds a layer of abstraction between your code and the hardware that native apps do not have, and while this gap has narrowed significantly, it still exists.
The business case: WebXR games trade raw performance for distribution advantages. A native Quest game might look slightly better, but it requires the player to find it in the Meta Store, download it, and install it. A WebXR game is one click away from any link on the internet. For ad-supported games, viral games, demos, and any scenario where reducing friction matters more than maximizing graphical fidelity, WebXR is compelling. Our deep dive on WebXR readiness covers the full picture.
The trajectory is clear. Browser vendors are investing in WebXR through the Interop 2026 initiative. Hardware is getting faster with each headset generation. WebGPU is arriving as a replacement for WebGL, promising better GPU utilization and compute shader support. The gap between native and web XR experiences is closing, and for a growing category of games, it has closed enough to ship real products.