Web Bluetooth for Fitness Apps in the Browser (2026)

Web Bluetooth is one of those APIs where the interesting engineering question is settled before you write a line of code. The API is capable, the profiles are the standard ones, and the browser support matrix decides whether your product can exist. So start there.

Where it runs#

Per the caniuse dataset, which is the source we checked:

Support also varies by operating system. The listed platforms are Windows, macOS, Linux, Android from M, and ChromeOS.

On iOS specifically: there is no native support in Safari, and a third-party app exists that polyfills the API — it is not WebKit, and it is not something you can assume any of your users have. A web page loaded in Safari on an iPhone cannot connect to a heart rate strap, and no amount of feature detection changes that.

Feature-detect anyway. Not because it will rescue the unsupported browsers, but because the alternative is a page that appears to hang when a user opens it in Firefox. Detect, and route to whatever your fallback is — a native app, a manual entry form, or an honest explanation.

Why the profiles are the same ones#

The reason Web Bluetooth is worth considering at all is that it is not a separate ecosystem. A browser-based fitness page talks to the same SIG-standard GATT services a native app does: Heart Rate (0x180D) with its Heart Rate Measurement characteristic (0x2A37), the Fitness Machine Service (0x1826) for gym equipment, Cycling Power (0x1818), Cycling Speed and Cadence (0x1816), Running Speed and Cadence (0x1814).

That has a real architectural payoff. The parsing, the unit handling, the reconnection semantics and the domain model you build for Bluetooth heart rate monitors or FTMS machines are not browser-specific work — they are the same concepts you would implement in Core Bluetooth on iOS. Only the transport API differs. Teams that write their device layer against the profile rather than against the platform API end up with the browser version as a port rather than a rewrite.

For wire formats, go to the FTMS specification published by the Bluetooth SIG and the corresponding SIG service specifications. We are not going to paraphrase packet layouts from memory here, and neither should your implementation.

Secure context and user gesture#

The API is designed to require a secure context and an explicit user action before a page can reach a device — you do not get to scan for nearby sensors on page load. We were unable to reach the primary source for the exact requirements this session, so check the current specification text rather than treating any particular phrasing as settled.

Plan the product around the shape of it regardless. Device selection is a user-initiated moment, not something that happens in the background while a page warms up, and that constrains the interface: there will be a button, the user will press it, and a chooser will appear. Design for that instead of hoping to hide it.

Where the web version is the right call#

Three product situations where our judgement is that Web Bluetooth earns its place.

Gym and studio kiosks. You control the hardware, you control the browser, and Chromium on a fixed screen is a completely reasonable target. A rowing machine or bike feeding a leaderboard display is exactly the case where "Chromium only" costs nothing. Rowing machine data and indoor bike trainer integration cover the profile side.

Desktop-first tools. Coach dashboards, lab setups, bike-fitting rigs, internal test harnesses. The users are at a computer, you can specify the browser, and shipping a web page is dramatically cheaper than shipping a signed desktop application.

Prototypes and device exploration. Before you commit to a native BLE layer, a browser page is the fastest way to see what a machine actually advertises and what it actually sends. That alone justifies knowing the API exists.

Where it is not#

Any consumer product that must reach iPhone users in the browser. This is not a hedge or a "degraded experience" caveat — Safari on iOS does not support the API, so the connect flow does not exist there. If iPhone reach in a browser is a requirement, Web Bluetooth is not the technology, and the decision is a native app or a different data source entirely, such as an account-level sync through wearable data APIs.

The same applies, less dramatically, to Firefox users on desktop. If a meaningful share of your audience is there, plan the fallback before you build the happy path.

One more honest caveat about machines#

If you are planning browser-based control of gym equipment — changing resistance or incline rather than just reading data — note that FTMS defines a Fitness Machine Control Point characteristic (0x2AD9), and that integrators commonly report that many machines broadcast data while ignoring or restricting remote-control commands outside the manufacturer's own app, varying by model and region. Treat control as a per-model capability you have to test on the actual hardware, in the browser you intend to ship, not as something the profile guarantees. FTMS goes into what the specification defines; testing BLE fitness device integrations covers how to find out what a specific machine does.