CURIOUS MINDS. NEW DIMENSIONS. A CLEARER VIEW.
The spatial web

WebXR and the Spatial Web: How Browser-Based 3D Experiences Work

Follow a spatial experience from web page to XR session, with a clear guide to device support, permissions, tracking, interaction, and useful fallbacks.

Neon illustrated title card for WebXR and the Spatial Web: How Browser-Based 3D Experiences Work, branded HologramBrowser.com.

A browser can present a model you rotate with a mouse, a virtual environment viewed through a headset, or an object placed against the view of a room. These experiences share 3D content, but their display, tracking, and interaction requirements differ. Understanding those differences makes the spatial web easier to evaluate and easier to build for.

WebXR is one part of that system. It gives web applications a way to communicate with supported XR devices. The surrounding website still needs content, graphics, controls, and error handling. Our hologram browser guide explains the broader terminology; here, we will follow the practical steps that turn a web link into an interactive spatial experience.

Follow the model from page to display

Imagine opening a page about a mechanical assembly. The page downloads a 3D asset, prepares its materials, and displays a view of the object. A rendering library handles the geometry and lighting. Ordinary web controls might let you rotate the model or select a labeled part.

When an immersive experience is available, WebXR coordinates information about the viewer, relevant input sources, and frame timing. The application uses that information to draw the scene from the appropriate viewpoints. As MDN’s WebXR fundamentals explains, loading and rendering the model remain separate responsibilities.

This division matters when comparing demonstrations. A smooth orbiting model shows that the page can render 3D graphics. It does not establish which immersive modes, tracking features, or input devices the same page supports.

Choose the viewing mode around the task

WebXR defines three session modes. An inline session appears within the page. An immersive-vr session presents a virtual environment through an immersive device. An immersive-ar session blends rendered content with the user’s surroundings through supported hardware. A conventional web model viewer can also work without opening a WebXR session.

For an assembly, a page-based view may be enough to inspect a connector. AR could help someone understand its apparent size beside a workbench. VR could support exploring a larger training scene. Each choice changes the experience the designer must prepare.

Choose one useful activity before choosing a mode. “Find the release latch” gives a concrete starting point. “Make the page immersive” leaves the essential question unanswered: what should the visitor understand or accomplish after entering the scene?

Check capabilities on the actual combination

WebXR availability depends on the browser, operating system, device, and requested feature. Support for one session mode does not establish support for another. A headset, phone, and desktop can therefore offer different paths from the same URL.

A developer can check whether navigator.xr exists, then ask isSessionSupported() about the intended mode. The session request still needs error handling. Required features can cause the request to fail when unavailable; optional features allow an application to adapt when it can continue without them.

For a visitor, a useful compatibility message names the available experience: “Explore the 3D model on this device” is more helpful than a blank canvas. For a publisher, a test record should name the device, browser version, mode, and features actually exercised. Avoid turning one successful demonstration into a claim of universal support.

Make entry and permissions understandable

WebXR requires a secure context, normally HTTPS for a published site. Immersive entry needs a deliberate user action, and the browser applies permission requirements to the requested experience and features. An embedded experience may also depend on the host page’s permissions policy, including spatial tracking permission.

Place a clearly labeled entry button beside a short explanation of what will happen. Ask for the permissions needed by that task, at the point they become relevant. If someone declines, preserve their place in the ordinary page. Exiting XR should return to a sensible state with the selected model or lesson still available.

Place content within a reference space

Spatial tracking uses coordinate systems to relate the viewer, input devices, and virtual objects. WebXR reference spaces express those relationships. A floor-related space can help an application position content relative to an estimated floor; another experience may need coordinates centered near the viewer’s starting position.

AR placement adds another question: where in the surrounding environment should the model appear? A supported hit-test feature can provide candidate intersections with detected real-world geometry. The application must still guide placement, select an appropriate result, and respond when tracking is unavailable or changes.

A visible placement indicator and a reset control give the visitor a way to understand and correct the result. Keep real dimensions available when size matters. Our AR hologram explainer covers how virtual objects are presented in a view of the real world.

Design interaction for the inputs available

WebXR exposes input sources with targeting and action information. Depending on the system, interaction may involve screen taps, tracked controllers, or supported hand input. A page should discover the available input rather than assume everyone has the same controller or gesture vocabulary.

Translate the activity into a few explicit actions: select a part, rotate the assembly, reveal a label, and return to the starting view. Give each action visible feedback. A label that changes when selected can reassure someone that the system received their input.

Keep instructions short and close to the relevant control. Test with someone who has never used the demonstration; watching their first attempt often reveals unclear affordances that experienced creators overlook.

Keep the scene responsive and legible

A spatial scene must download, decode, and render its assets while handling interaction. Geometry, textures, transparency, animation, and lighting all contribute work. There is no useful universal file-size or polygon limit for every combination of scene and device. Measure the complete experience on its intended targets.

Start with a representative model and the most important interaction. Observe loading, moving around the object, opening labels, and leaving the scene. Remove detail that does not support the task, then compare the result at the distance visitors actually view it.

Text needs equal attention. Labels should remain readable against the scene, and controls should be easy to find after the viewpoint changes. For larger virtual environments, our VR hologram guide introduces the display and viewing conditions behind the apparent depth.

Keep the explanation usable outside XR

Build the ordinary page as a complete introduction to the content. Include a useful poster image, a concise description, dimensions where relevant, and a clear route to the key information. A visitor may have an unsupported device, limited bandwidth, or a preference for reading.

Preserve equivalent ways to answer the main question. An annotated diagram can identify the release latch, while a short text sequence can explain the assembly order. Keyboard access, meaningful control labels, and restrained motion help the page serve a wider range of visitors.

These alternatives also make review easier. An editor can verify terminology and instructions independently of the immersive scene, then check that the spatial version communicates the same information.

Review the whole journey before release

Test entry from a fresh visit, a declined permission request, an unsupported mode, a slow asset load, a tracking interruption, and a normal exit. Check that the experience recovers with a useful message and a working next step. Save enough context to reproduce failures.

If the model is embedded in another website, repeat the entry test there as well as on its own page. Host configuration can affect permission behavior, so a working standalone demonstration does not confirm that the embedded version will enter XR successfully.

For the assembly example, the final acceptance question is whether a visitor can locate the correct part and understand its function. Successful session creation is only one piece of that result.

Build a spatial experience with a clear purpose

The spatial web combines familiar web publishing with device-dependent ways to view and interact with 3D content. WebXR supplies a bridge to supported XR capabilities; a useful experience still depends on well-prepared assets, understandable controls, careful testing, and a complete surrounding page. Start with a question that benefits from depth, and choose the viewing mode that helps people answer it.

Have a question about this guide? Get in touch.
THERE’S MORE TO THE STORY

Keep exploring.

All guides

Stay curious.
There’s more to see.

Explore the journal