Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Awe.js is tied to the awe.media platform today: the project’s GitHub repository says the older standalone code has moved to a deprecated branch, while the latest version is included within awe.media apps. For browser-based AR, first choose the kind of experience you need—image tracking, GPS-based placement, or standards-based immersive AR—then verify that the intended device and browser support it.

How do I make an AR experience run in a browser?

“AR in the browser” describes how people access an experience, not a single technology or a guarantee that every browser can run every kind of AR. A web page can present different experiences using a platform’s own tracking features, or use the WebXR Device API to access immersive hardware where the browser and device support the requested mode.

Awe.media describes its JavaScript API as an awe object exposed in the page DOM. The API sits on top of THREE.js and provides access to scenes, media objects, interactivity, sensors, and device types. Its guides describe three distinct view types:

Approach What it does Main dependency What to test
awe.media image view Tracks an image or natural features to anchor digital content to a real-world image. The awe.media app and its image-tracking functionality. Target recognition, camera permission, and behavior on the intended device and browser.
awe.media location view Uses GPS-based placement for location AR. Location permission and device geolocation capability. Permission flow, location accuracy, and performance in the environment where people will use it.
WebXR immersive AR Lets a web page access AR or VR devices where the API and requested mode are implemented. Browser, device, and support for the exact immersive-ar session mode. Runtime feature detection and testing on the actual target devices.

The awe.media guide also describes standard 360-degree or VR views and says its view types can be linked within one app. These are awe.media product descriptions; they should not be treated as WebXR session modes. See the awe-media repository and platform guides for the project’s current framing.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A practical build sequence

  1. Pick the experience type. Decide whether the content should follow a printed or real-world image, appear at a GPS location, or use immersive AR hardware. The choice determines the tracking method and permissions to plan for.
  2. Choose the implementation path. For awe.media’s image, location, or standard views, follow the platform’s app guides. For a standards-based immersive experience, build against WebXR and request a session only after checking support for that mode.
  3. Plan permissions and fallbacks. Camera, geolocation, motion, orientation, and other device capabilities may be relevant depending on the experience. Explain why a permission is needed and give users a useful alternative when access is denied or unavailable.
  4. Test on the intended devices and browsers. Confirm that the target is recognized or the location is usable, that permissions behave as expected, and that unsupported modes fail gracefully. A page loading successfully does not prove that its AR features are available.

Is awe.js still maintained?

The repository’s current notice says the version of awe.js formerly hosted there has moved to a deprecated branch, and that the latest version is supplied inline as part of an awe.media app. The repository now serves as a collection of guides and examples for awe.media-based apps—not as the location of a current standalone framework download. The project page does not establish a separate current standalone release or its maintenance schedule.

If you are starting a project, use the current awe.media guides to understand the platform workflow rather than treating the deprecated branch as the latest distribution. The repository describes creating hosted apps, activating them for public release and additional capabilities, and purchasing optional features; it does not establish current prices or partner terms.

Does browser AR require an app download?

Not necessarily. A browser-based experience can be opened from a web link without installing a native app, but the browser still needs the required device capabilities and implementation support. Depending on the approach, the experience may need camera, location, motion, or orientation permissions. An immersive WebXR experience also depends on whether the browser supports the particular session mode on that device.

For awe.media, the documented delivery model is an awe.media app accessed through the web; the repository says the latest awe.js version is inline within those apps. That is different from downloading a native app, but it does not make every awe.media view or WebXR feature universally available.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How do I check whether my browser supports immersive AR?

Check capabilities at runtime rather than guessing from the browser’s name or user-agent string. Google’s WebXR tutorial first checks whether navigator.xr exists, then calls navigator.xr.isSessionSupported("immersive-ar") before enabling its entry button. The second check matters: an available WebXR API does not mean the device supports every session mode.

async function supportsImmersiveAR() {
  if (!navigator.xr) return false;

  try {
    return await navigator.xr.isSessionSupported("immersive-ar");
  } catch {
    return false;
  }
}

const arButton = document.querySelector("#start-ar");
arButton.disabled = !(await supportsImmersiveAR());

This is a capability check, not a complete AR implementation. In a real page, connect the button to session setup, handle failures that occur when requesting a session, and provide a non-immersive alternative or a clear explanation if the check fails. Follow the Google WebXR AR tutorial for its example flow.

Meta’s WebXR guidance likewise recommends runtime feature detection rather than inferring support from the user-agent string. Test the exact combination of device, browser, and requested mode on real hardware. The Meta Horizon OS WebXR overview is relevant to its platform, but its guidance is not a compatibility guarantee for other devices.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What is the difference between image tracking, location-based AR, and WebXR?

Image tracking

Image or natural-feature tracking anchors content to something the camera can recognize in the scene. It suits experiences where an image or visual target should trigger or position content. Test the actual target under the lighting, distance, and camera conditions users are likely to encounter, as well as the camera permission flow.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Location-based AR

Location AR uses geolocation to place content in relation to a real-world position. It depends on location permission and usable location data, so test accuracy and the intended environment rather than assuming a GPS fix will be precise enough everywhere.

WebXR immersive AR

WebXR is a standards-based API for web access to AR and VR devices, including sensors and head-mounted displays. The W3C specification says it describes “support for accessing virtual reality (VR) and augmented reality (AR) devices, including sensors and head-mounted displays, on the Web.” The cited W3C page identifies the document as a Candidate Recommendation Draft dated June 9, 2026, intended to become a Recommendation, and labels it work in progress. A standards document describes the API; it does not show that every browser implements every feature.

For patterns beyond a single tutorial, the Immersive Web WebXR Samples provide examples; the sample site identifies glTF 2.0 as the model format used for its samples. Treat examples as implementation references, not proof of device compatibility.

What should I test before publishing?

  • Capability and mode: For WebXR, check both API availability and support for immersive-ar; do not rely on user-agent matching.
  • Permissions: Exercise camera or location access, including denied, delayed, and unavailable cases.
  • Tracking or positioning: Try image targets in realistic camera conditions, or location experiences in their intended environments.
  • Fallback behavior: Provide a useful response when tracking, location, or immersive mode is unavailable instead of leaving an unusable start control.
  • Target hardware: Test the actual device/browser combinations your audience will use. No universal compatibility claim follows from the fact that an experience is delivered by a web page.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.