The Web Bluetooth API is frequently mentioned in proposals for beacon-based projects, often presented as a way to avoid building a native app. In practice, the API carries constraints that make it unsuitable for most proximity deployments. Understanding where it breaks down — and what to use instead — prevents costly pilot failures and unrealistic project timelines.
Web Bluetooth API: Browser Support and Constraints
The Web Bluetooth API allows a web page to communicate with nearby Bluetooth Low Energy devices directly from the browser, without a native application. It was designed primarily for interacting with GATT-based peripherals: heart-rate monitors, smart lights, sensors that expose readable and writable characteristics.
Browser support is the first practical barrier. MDN currently marks Web Bluetooth as experimental and not Baseline because it is unavailable in some widely used browsers. Support, permission behaviour and background limits must therefore be checked against the exact browser and operating-system combinations used by the intended audience immediately before launch.
Several additional constraints apply even on supported platforms:
- HTTPS required. The API is only available over secure contexts. Local development is possible via localhost, but any staging or production environment needs a valid certificate.
- User gesture required. A call to
navigator.bluetooth.requestDevice()must originate from a user-initiated event such as a tap or click. Automated or background scanning is not possible. - Device picker interaction. On most implementations, the browser presents a system dialog asking the user to select a specific device. This interrupts the user journey and is poorly suited to passive proximity detection.
- GATT connection model. The API is built around connecting to a device and reading or writing GATT services and characteristics. It is not designed to passively receive advertising broadcasts from beacons.
That last point is the fundamental architectural mismatch. Beacons do not generally expose GATT services for arbitrary connections. They broadcast small packets on advertising channels. The Web Bluetooth API is not an advertising-packet scanner; it is a GATT client. Some beacon hardware does support GATT connections for configuration, but relying on that for a visitor-facing proximity experience is impractical at scale.
Why Web Bluetooth Is Not a Universal Solution
The expectation that Web Bluetooth might replace native apps for beacon interaction stems from a reasonable desire: reduce friction by letting visitors tap a link or scan a QR code that opens a web page, which then detects nearby beacons. The technology does not support this workflow.
Passive beacon detection requires the device to continuously or periodically scan advertising packets in the background, match received identifiers against a known list, and trigger actions when a beacon enters or leaves range. Native operating systems provide this capability through dedicated BLE scanning APIs. The Web Bluetooth API provides none of it.
A web page using Web Bluetooth can only discover and connect to devices when the user actively triggers the process and the page is in the foreground. Even then, it is looking for connectable devices with specific GATT service UUIDs, not listening for advertising packets from anonymous beacons. The result is a workflow that demands deliberate user action for each interaction, which defeats the purpose of ambient proximity detection.
For venue operators, the practical consequence is straightforward: if your use case depends on a visitor walking past a beacon and receiving a notification or content trigger without manual intervention, Web Bluetooth cannot deliver it. If your use case involves a visitor actively choosing to connect to a specific piece of hardware — a rental device, an interactive exhibit with a configurable BLE peripheral — Web Bluetooth may be viable, but only on platforms where the browser supports it.
Platform fragmentation in practice
A UK retail or museum audience will use a changing mix of browsers, operating systems and managed devices. MDN currently marks Web Bluetooth as experimental and not Baseline, so the venue should test the exact supported combinations and present QR or NFC as a first-class alternative rather than hiding it behind an error state.
Progressive Web Apps and Beacon Interaction
Progressive Web Apps add service workers, offline caching and installability to web applications, but they do not extend the Web Bluetooth API's capabilities. A PWA running in a browser tab is subject to the same constraints: no background scanning, no advertising-packet reception, no dependable cross-browser iOS support, and the same user-gesture and device-picker requirements.
Current browser implementations do not expose Web Bluetooth to service workers as a dependable background-scanning mechanism. A service worker can respond to push notifications or fetch events, but it cannot scan for beacons. This means a PWA cannot wake itself when a visitor approaches a beacon zone.
Some deployments described as "PWA beacon solutions" are in fact hybrid applications: a web-based UI wrapped in a thin native shell — using technologies such as Capacitor, Cordova or a custom native wrapper — that accesses the platform's native BLE scanning APIs. This is a legitimate architecture, but it is not a pure web solution. It requires app-store distribution, native build pipelines and platform-specific Bluetooth permission handling. The "PWA" label in these cases refers to the front-end technology, not the delivery mechanism.
When evaluating a supplier claiming PWA-based beacon support, a useful question is whether their solution works in a standard mobile browser without any app installation. If the answer involves installing something from an app store, it is a native or hybrid app, and the Web Bluetooth limitations described here do not apply in the same way — but the operational overhead of native distribution does.
Fallback Strategies When Web Bluetooth Is Unavailable
For projects where a native app is not viable — because of download friction, development budget, or the one-off nature of an event — several alternatives sit alongside or instead of beacons.
QR codes at point of interaction. A printed or digital QR code placed at the exact location where content should trigger avoids the need for any background scanning. The visitor scans the code and receives the relevant web page. This is the most reliable no-app approach. Dynamic QR codes allow the destination URL to be changed without reprinting, which is useful for rotating exhibitions or seasonal retail displays. The limitation is that the visitor must physically locate and scan the code, which removes the ambient discovery aspect of beacons.
NFC tags for close-range triggers. An NFC tag embedded in a display, shelf edge or exhibit panel can open a URL with a single tap on most modern smartphones. No app is required. NFC can work on supported iOS and Android devices, subject to device settings, tag type and the user journey. The constraint is physical range: the phone must be within a few centimetres of the tag, which makes NFC suitable for point-of-interest content but not for zone-level detection or navigation.
Hybrid app-and-web architecture. Some venues deploy a native app solely for beacon interaction and background scanning, but serve all content through web views or standard URLs. The app handles the proximity trigger; the browser handles the experience. This reduces native development to a thin integration layer while keeping the content management on the web.
Reassessing whether beacons are needed. If the project cannot justify a native app and the use case does not require background or zone-level detection, beacons may be the wrong technology. QR and NFC cover most point-of-interest content delivery without platform fragmentation. Beacons earn their place when the experience depends on detecting a visitor's presence in a zone without requiring them to take any action — queue detection, dwell-time analytics, automatic wayfinding triggers — and that inherently requires native capabilities.
The decision framework is not about choosing between Web Bluetooth and native apps in the abstract. It is about matching the interaction model to the technology that actually supports it. If the interaction model requires passive detection, Web Bluetooth is not an option, and the project must either accept a native app, use a manual trigger like QR or NFC, or reconsider the use case entirely.
Progressive Web Apps do not remove platform limits
Installing a web experience as a Progressive Web App can improve launch, caching and interface behaviour, but it does not create Bluetooth capabilities that the browser and operating system do not expose. Web Bluetooth remains experimental and is not Baseline. Treat it as an explicit, user-initiated interaction on verified device/browser combinations, not as a universal background beacon channel.
