When it comes to webar world tracking, there is a moment in every good AR demo when the scepticism evaporates. It is not when the 3D model appears — it is when the user walks around it and it stays put. The virtual chair remains exactly where they left it, occluded correctly by the real coffee table, lit as if it belongs in the room. That feeling of persistence — digital things behaving like physical things — is the whole game. And it is delivered by world tracking.

World tracking is the technology that lets a device understand the physical space around it: where the floor is, where the walls are, how the camera is moving through it all. In native apps it has been mature for years. In the browser — WebAR — it is newer, more constrained, and more interesting, because it has to work instantly, on any phone, with no install.

This article explains how world tracking works in WebAR, what the browser can and cannot do today, and the best practices we use at Visuosofts when building immersive world-tracked experiences for clients.

What world tracking actually is – Webar World Tracking

Strip it down and world tracking answers two questions, continuously, dozens of times per second: where am I? and what is around me?

'Where am I?' is camera pose estimation — the device's position and orientation in space, tracked as the user moves. 'What is around me?' is scene understanding — detecting horizontal and vertical planes (floors, tables, walls), estimating depth, and increasingly understanding lighting and occlusion. Together they create a shared coordinate system where virtual objects can be placed with the persistence of real ones.

The core technique is SLAM — simultaneous localisation and mapping. As the camera moves, the system identifies visual feature points in the environment (corners, textures, edges), triangulates their 3D positions from multiple viewpoints, and uses them both to build a map of the space and to locate the camera within it. It is genuinely remarkable mathematics running in real time on a phone, and it is why AR works at all.

How world tracking reaches the browser

WebAR world tracking arrives through two main routes, and choosing between them is the first architectural decision in any project.

Route 1: WebXR Device API

WebXR is the open web standard for VR and AR, supported natively in Chrome on Android (and increasingly elsewhere). A WebXR AR session gives the page direct access to the device's tracking: the browser exposes camera poses, detected planes and anchors through a standard API, with the heavy SLAM lifting done by the device's own AR framework underneath (ARCore on Android).

The advantage is capability and cost: it is a free, open standard with access to genuinely good tracking, including plane detection, anchors and — where the hardware supports it — depth sensing for occlusion. The limitation is reach: full WebXR AR requires a compatible browser and device, which in practice means modern Android phones in Chrome. iOS Safari's WebXR AR support has been the long-standing gap, though the situation continues to evolve.

Route 2: commercial WebAR SDKs

SDKs such as 8th Wall pioneered world tracking in the mobile browser before WebXR AR was viable, using computer-vision SLAM implemented in JavaScript/WebAssembly. Their defining advantage is cross-platform reach: the same experience runs on iOS and Android from a single link, which is why they power most large-scale WebAR marketing campaigns.

The trade-off is licensing cost and a tracking stack that, while excellent, runs above the OS rather than inside it. For campaigns where reach across both mobile platforms matters more than squeezing the last 10% of tracking fidelity — which is most marketing work — this is usually the right call. When we scope WebAR development projects, platform reach vs tracking depth is one of the first conversations we have with clients.

Route 3: model-viewer and lightweight AR

For product visualisation specifically, Google's <model-viewer> web component deserves a mention. It renders interactive 3D in the page and hands off to the platform's native AR (Scene Viewer on Android, Quick Look on iOS) for placement. It is not a full world-tracking toolkit — you get place-and-view rather than a scripted immersive scene — but for 'view this sofa in your room' it is free, robust and remarkably effective. Many AR e-commerce implementations start here.

The building blocks of a world-tracked scene

Whatever the route, immersive WebAR scenes are assembled from the same set of tracking primitives. Understanding them is what separates experiences that feel magical from ones that feel broken.

Plane detection

Planes are the foundation: the system identifies flat surfaces — floors, tabletops, walls — and reports their position, extent and orientation. Good experiences do not just dump a model at the first detected plane; they guide the user ('point your camera at the floor and move slowly'), visualise the detected surface subtly, and only enable placement when tracking confidence is high. The single biggest cause of 'AR feels janky' is placing content before the tracker has a stable map.

Anchors

An anchor pins a virtual object to a real-world position. As the SLAM map refines itself, anchors update so content stays glued in place. For multi-object scenes — a room layout, a product display, a trail of waypoints — everything hangs off anchors. Design rule: anchor the things that must not move, and be honest in testing about drift on long sessions. Anchors are excellent over minutes; over tens of minutes in featureless spaces, expect some wander.

Occlusion

Occlusion is what sells the illusion: real objects correctly hiding virtual ones. Walk behind your real sofa and the virtual chair should disappear behind it. True occlusion needs depth information, which on the web is the hardest primitive to get — it depends on device depth sensors or software depth estimation, both unevenly available. Pragmatic approach: design scenes that minimise the need for occlusion (open floor areas, tabletop scenes), fake it where you must with simple depth tricks, and treat real occlusion as a progressive enhancement.

Lighting estimation

A virtual object lit like a studio render sitting in a dim living room looks fake instantly. Lighting estimation samples the camera feed to approximate ambient light direction, intensity and colour temperature, then lights the 3D content to match. Even coarse estimation transforms believability. Always enable it where the platform offers it, and build materials that respond to light rather than flat-shaded colours.

Hit-testing and raycasting

Hit-testing converts a screen tap into a real-world position — the 'tap to place' interaction. It raycasts from the tap point into the tracked scene and returns where the ray meets a detected plane. Responsive, forgiving hit-testing (generous tap targets, clear placement preview before confirming) is the difference between an experience that feels effortless and one that feels fiddly.

Best practices for immersive world-tracked WebAR

Technology is only half the story. The practices below come from shipping real WebAR campaigns, and most of them are about managing the gap between what tracking promises and what a user's living room delivers.

Design the onboarding, not just the scene. The first fifteen seconds decide everything. Show the user what to do: a short animation of 'move your phone slowly to scan the room', a clear scanning state, and feedback the moment tracking locks. Users who understand the ritual get good tracking; users who are confused wave the phone randomly and blame the technology.

Respect the environment. World tracking loves texture and hates blankness. A white wall, a dark room, a glossy floor — all tracking-hostile. Design experiences that work in ordinary rooms: encourage scanning textured areas, keep critical interactions in the central field of view, and degrade gracefully (a fixed-scale tabletop mode as fallback) rather than failing outright.

Keep scenes performant. Tracking already consumes significant CPU/GPU; your 3D content competes for what is left. Optimise models ruthlessly — polygon counts, texture sizes, draw calls — and test on mid-range devices, not flagships. A beautiful scene at 12fps feels worse than a simple scene at 60fps. Immersion is a frame-rate phenomenon.

Use scale honestly. True-to-scale content is AR's superpower and its strictest discipline. A product rendered at the wrong scale does not just look wrong — it teaches the user that nothing in the scene can be trusted. Verify scale against real measurements for every product model.

Plan for the session arc. Immersive does not mean endless. The best world-tracked experiences have a clear arc — scan, discover, interact, capture/share — lasting a few minutes. Instrument drop-off points and iterate: if users consistently bail at the same step, that step is broken, not the users.

Test in real spaces. Lab testing lies. Offices have great lighting and textured carpets; users have dim bedrooms and featureless magnolia walls. Test in the worst rooms you can find, on the oldest phones you support, with users who have never used AR. That is your actual audience.

Current limits — stated plainly

An honest technical article should name the constraints. Persistent world maps — the same AR content appearing in the same spot for every visitor, days apart — remain limited in browser AR compared with native; multi-user shared AR sessions in WebAR are early-stage; and tracking quality varies enormously between a flagship phone in a bright room and a budget device in a dim one.

None of this makes WebAR unsuitable — it makes brief-writing important. The experiences that succeed are designed inside these constraints: single-user, session-scoped, forgiving of imperfect spaces, brilliant within a few square metres. Some of the most effective commercial WebAR ever built is a product on a floor. Constraints, respected, become focus.

Where world tracking in WebAR is heading

The trajectory is clear: browser AR capabilities are converging with native, driven by WebXR maturation, improving on-device ML for depth and occlusion, and the gradual arrival of AR eyewear that will need web content. For brands, the strategic point is that world-tracked experiences built today — the 3D assets, the interaction patterns, the analytics — transfer directly to whatever comes next. The content is the durable investment; the delivery layer keeps improving underneath it.

If you are planning an immersive WebAR experience — product placement, a brand world, an interactive installation preview — the tracking decisions you make at the start determine whether it feels magical or broken. At Visuosofts, AR development is our core discipline: we scope the right tracking route for your audience and devices, build the 3D content, and test in real-world conditions before launch. Talk to our team about what you want to put into the world — we will tell you honestly what the browser can do with it.

For more information, see GOV.UK.