When it comes to world tracking webar, most WebAR experiences you have seen are simple: tap a button, a 3D sofa appears on the floor in front of you. That works because the phone found a flat surface. But the moment you want a virtual object to stay put while you walk around a room — a piece of machinery anchored to the factory floor, a navigation arrow fixed to a corridor, a sculpture that stays on its plinth as you circle it — you need something more capable. You need world tracking.
World-tracked SLAM WebAR is the technology that makes this possible in a mobile browser, with no app to download. This guide explains how it works, what it can and cannot do, and where it fits for businesses planning AR projects in 2026.
What world tracking actually means – World Tracking Webar
In AR, tracking is the system's understanding of where the phone is in the physical world. Basic WebAR uses plane detection: the phone's camera spots a flat surface — a floor, a table — and places the virtual object on it. Move the phone and the object roughly stays where you left it, but the system has no real understanding of the room. Walk too far, point the camera at a blank wall, and the object drifts or vanishes.
World tracking is a step up. Instead of finding one flat surface, the system builds a continuous map of the environment and tracks the phone's position within it — six degrees of freedom (position and rotation) as you move through space. Virtual objects are anchored to points in that map, so they stay fixed in the world while you walk around them, leave the room and come back.
SLAM — Simultaneous Localisation and Mapping — is the technique that makes this possible. The name describes exactly what it does: the device maps the environment and locates itself within that map at the same time, in real time, using the camera feed plus motion sensor data. It is the same core technology behind robot vacuum cleaners that learn your floor plan and self-driving car prototypes that navigate streets. In WebAR, a SLAM implementation runs in the browser and gives web-based AR something close to the tracking quality of a native app.
How SLAM works (in plain English)
You do not need the mathematics, but the intuition matters — because it explains both the strengths and the limits.
As you move the phone, SLAM looks for distinctive visual features in the camera image: corners, edges, textured patches — anything stable and recognisable. It tracks how those features move between frames and combines that with data from the phone's accelerometer and gyroscope, which report how the device itself is moving. From these two sources, it triangulates: the features must be at certain positions in 3D space, and the phone must be at a certain position relative to them.
Over a few seconds of movement, this builds a sparse 3D map of the surroundings — a cloud of points marking where the distinctive features are — and a continuously updated estimate of the phone's position within it. Virtual objects are then placed at coordinates in that map, which is why they stay put: the system knows where the phone is relative to everything it has mapped.
Two consequences follow. First, SLAM needs visual texture and movement to work. A richly textured room maps quickly; a plain white wall gives it nothing to hold onto. Second, the map is built as you move — the first few seconds of an experience, while the user waves the phone around, are the system learning the space. Good WebAR experiences design for this with onboarding prompts (move your phone slowly to scan the room) rather than pretending tracking is instant.
World tracking vs the other WebAR approaches
It helps to place world tracking alongside the alternatives, because each suits different jobs.
Marker-based AR uses a printed image — a QR-style marker — as an anchor. It is cheap, reliable and precise, but it requires the marker to exist in the world. Fine for packaging and print campaigns; useless for anchoring a virtual machine to an empty factory floor.
Plane detection (what most basic WebAR product viewers use) finds horizontal or vertical surfaces with no marker. It is the right choice for place this sofa here experiences — simple, fast, widely supported. But it has no persistent understanding of the space: objects are placed relative to a detected plane, not anchored in a world map.
World tracking with SLAM builds the persistent map. It is the right choice when virtual content must stay fixed in space across movement: wayfinding arrows in a building, machinery positioned on a factory floor, multi-room experiences, anything the user walks around or returns to. The cost is complexity — more processing, more sensitivity to the environment, and a smaller set of web platforms that support it well.
Location-based AR (GPS-anchored) is a separate category: it places content at geographic coordinates rather than mapping the immediate surroundings. Useful for outdoor trails and tourism, but GPS accuracy (several metres) makes it unsuitable for precise placement.
The honest summary: plane detection handles most retail use cases; world tracking earns its complexity when persistence and precision in space are the point of the experience.
How world-tracked WebAR runs in a mobile browser
This is where the practical reality of 2026 matters. On Android, the Chrome browser can access WebXR — the web standard for AR and VR — which exposes the phone's AR capabilities (including ARCore's tracking) to web pages. A world-tracked WebAR experience on Android can therefore use genuinely capable tracking through an open standard.
On iPhone, the picture is different. Safari does not support WebXR, and Apple has not indicated that it will. World-tracked WebAR on iOS therefore relies on commercial WebAR platforms that implement their own SLAM in JavaScript/WebAssembly — most notably 8th Wall, which pioneered this approach — or on AR Quick Look, Apple's built-in viewer, which handles single-object placement well but is not a full world-tracking platform.
The practical consequence: a world-tracked WebAR project in 2026 almost always builds on a commercial platform (such as 8th Wall) or a carefully chosen open-source stack, and it must be tested on both Android and iOS because the tracking behaviour differs between them. Any agency that tells you it just works the same on every phone has not shipped one of these. Cross-device testing is not optional — it is where most of the QA budget goes.
Performance is the other reality. SLAM is computationally expensive, and it runs alongside 3D rendering on a phone processor. World-tracked experiences need disciplined 3D optimisation — polygon budgets, texture sizes, draw calls — far more than a simple product viewer does. Optimised 3D models are not a nice-to-have here; they are the difference between smooth tracking and a juddering mess.
Accuracy and limitations — the honest part
World-tracked WebAR is impressive, but it is not magic, and a guide that skipped the limits would be a sales brochure. Here are the ones that matter in practice.
Drift. Over long sessions or large spaces, small tracking errors accumulate and anchored objects gradually shift from their true position. For a five-minute product demo this is rarely noticeable; for a warehouse-scale wayfinding experience it is a genuine engineering problem that needs relocalisation strategies (re-anchoring to known features).
Environment dependence. SLAM loves texture and hates blankness. A featureless white showroom, a dark warehouse, or a space full of moving people will degrade tracking. If your deployment environment is challenging — low light, reflective floors, crowds — say so during scoping, because it changes the technical approach.
No true occlusion by default. Knowing where the phone is does not automatically mean virtual objects hide correctly behind real ones. Depth-based occlusion (a virtual chair correctly hidden behind a real table) needs depth data or machine-learning depth estimation, which is heavier still. Many WebAR experiences skip true occlusion and design around it.
Battery and heat. Continuous camera, SLAM computation and 3D rendering drain batteries fast. Experiences longer than a few minutes should be designed with this in mind — and kiosk or event deployments should plan for charging.
Browser and OS fragmentation. As covered above, Android and iOS take different paths to the same result. OS updates can and do change tracking behaviour. Budget for ongoing testing, not just launch testing.
None of these are reasons to avoid world-tracked WebAR. They are reasons to scope it honestly and to work with a team that has shipped it before.
Where businesses actually use it
World tracking earns its place in a specific set of commercial use cases:
- Industrial visualisation: placing full-scale machinery on the factory floor to check fit, plan installations and train operators — the strongest ROI case, because the alternative is shipping physical equipment.
- Wayfinding and tours: arrows and information anchored in buildings, museums, campuses and exhibition halls, persisting as visitors move through space.
- Construction and property: overlaying planned builds onto sites, or walking buyers through an off-plan development anchored to the actual plot.
- Events and brand experiences: large-scale installations where virtual content must stay fixed while crowds move around it — product launches, exhibitions, festivals.
- Training: step-by-step instructions anchored to real equipment, where each step must appear at the right physical location in the right order.
Notice what is not on the list: basic product visualisation. If the job is see this sofa in your room, plane detection does it with less cost and wider compatibility. World tracking is for when the content must live in the space, not just visit it.
What a world-tracked WebAR build involves
A typical project runs through four stages. First, scoping the space: the physical environments where the experience will run are assessed for tracking suitability — lighting, texture, scale, crowd levels. This step is frequently skipped and frequently regretted.
Second, content and 3D production: the virtual objects, built to strict performance budgets. For industrial use cases this often means converting existing CAD data into real-time-ready models — a specialist job, since CAD models are far too heavy for mobile browsers as they stand.
Third, experience development: the WebAR application itself — SLAM-based anchoring, interaction design, onboarding that teaches users to scan their space, and fallbacks for devices or environments where tracking struggles.
Fourth, testing across the device matrix: flagship and mid-range Android phones, several iPhone generations, in lighting conditions matching the real deployment. This is where world-tracked projects differ most from simple WebAR: the QA burden is real and must be budgeted.
Timelines and costs vary widely with the complexity of the environment and content, but expect a world-tracked build to cost materially more than a plane-detection product viewer — you are paying for the tracking engineering and the testing, not just the 3D.
Is world-tracked WebAR right for your project?
Ask three questions. Does your content need to stay fixed in physical space while users move around it? Will it run in environments you can assess and design for? And does the value justify the engineering — is this a high-value sale, a large audience, or a repeated operational use?
Three yeses, and world-tracked WebAR is worth scoping. If the real need is simpler — visualising products, trying on items, scanning a code for information — the lighter approaches will serve you better, cheaper and faster.
We build WebAR experiences across this whole spectrum — it is core to our AR development work — from simple product viewers to SLAM-based world tracking, and we will tell you which end of it your project belongs at. Get a free consultation — bring the space, the use case and the scepticism, and we will give you a straight answer.
For more information, see GOV.UK.