Bluetooth Device Checker

This page used to call getAvailability()and print “Bluetooth appears available to this browser” when it resolved true. That reading is wrong, and the specification is unusually blunt about why. It instructs the browser that if the system has a Bluetooth radio it should “resolve promise with true regardless of the powered state”, and the accompanying note spells out the consequence: “An adapter that’s disabled through software should count as available.”

So the method answers a question about hardware inventory, not about readiness. Somebody with Bluetooth switched off in system settings got a green tick and the word available, which is the exact opposite of what they needed to know. The row is now labelled Radio present, carries a “presence, not power” tag, and says in plain words that it cannot see the on/off state.

The second correction is smaller but the same kind of mistake. When a browser had the API but no getAvailability(), the old code set availability to “available” — inventing a positive result out of a missing measurement. An absent probe is now reported as undetermined, which is what it is.

The previous version printed a GATT row reading “Not connected” for every device you picked. It was technically accurate and completely useless, because it could never say anything else. When the browser hands a page a device object, the spec has the connection state “initialized to false” — choosing a device does not connect to it. Reading that field immediately after the chooser closes is reading a constant.

That mattered because the distinction is the whole diagnostic. Granting access means the browser will let this origin talk to that device. Connecting means the device answered. A headset that appears in the chooser and then refuses a connection is a completely different fault from one that never appears, and the old page collapsed both into the same output.

There is now an explicit GATT test that calls connect(), reports the result, and then disconnects, because leaving a web page holding an open connection to your headphones is not a courtesy. If it fails, the error name and message are printed rather than smoothed into a generic failure.

Devices granted in earlier sessions are also listed now, through getDevices(), which needs no click because the permission already exists. Worth knowing what that list is not: the spec cautions that those devices “may not be in range of the Bluetooth radio”. It is a record of permissions, not a scan.

This is the most common disappointment with the API, and it is a scope limit rather than a bug. Everything here runs through GATT — the attribute protocol built for Low Energy. The spec notes that GATT “can also run over BR/EDR transport”, so Classic devices are not excluded on paper, but the access surface is still GATT services. Generic socket or stream access was left out on purpose, because constraining the API to GATT “denies malicious websites access to most parsers on the device”.

An A2DP speaker or a Classic headset does not expose its audio through GATT, so even when it appears you cannot do anything with it. The spec concedes this directly: over BR/EDR the advertised data cannot distinguish GATT from non-GATT services, so a user may well choose a device “this API provides no way to interact with”. If your accessory works through the operating system but not here, that is the usual reason.

Discovery has its own quirks. Scanning runs the Low Energy General Discovery Procedure, which only sees devices actively advertising. A tracker already paired to your phone has usually stopped advertising, and a device that only advertises for a minute after a button press will be invisible the rest of the time. Hold the pairing button, then open the chooser — in that order.

One detail that surprises people: an empty scan does not mean an empty chooser. The spec says to prompt the user “even if scanResult is empty”. A chooser with nothing in it is the expected appearance of a failed scan, not a broken dialog.

The ID next to each device is not its hardware address. Among the API’s stated defences is that it “never exposes Bluetooth addressing, data signing or encryption keys” to a site. The value is minted by the browser when it records the permission, and it identifies the device only “to the extent that the UA can determine that two Bluetooth connections are to the same device”.

The privacy guidance goes further and is worth reading as a user rather than a developer. It says users “generally don’t intend two different origins to know that they’re interacting with the same device”, and that they “generally don’t intend unique identifiers to persist after they’ve cleared an origin’s cookies”. So the identifier you see here should be specific to this site and should disappear when you clear this site’s data.

The stated reason for that caution is concrete: a persistent device identifier, combined with a catalogue of known devices, could be used to work out where someone is. That is why the browser stands between the page and the radio at every step, and why a page that could enumerate your surroundings silently would be a location tracker wearing a diagnostic’s clothes.

A name can be missing, and that is normal. The name field is nullable, and a device “has a partial name when the Shortened Local Name AD data was received, but the full name hasn’t been read yet”. An unnamed entry is a device that has not advertised a full name yet, not a device that is hiding.

Work down the rows in order, because a red row makes every row under it meaningless. No secure context means the permission state is denied before anything is asked. No API means the radio question cannot be put. Only when support and presence both pass is a chooser failure telling you something about your devices rather than about your browser.

A SecurityError almost always means the call did not come from a genuine click, or the page is inside a frame that has not been granted the bluetooth permissions-policy feature. The spec requires transient activation for a device request and rejects otherwise, so an automated or deferred call fails by design.

If the checks pass, the chooser lists your device, and the GATT test still fails, the browser has done its part. That pattern points at the link between the device and the operating system: already connected to another host, out of battery, or holding a stale pairing that needs removing and redoing at the OS level.

Test on a second browser before concluding the device is faulty. Two Chromium browsers on the same machine share the platform radio but keep separate permission stores, so a device that works in one and not the other points at a stored permission rather than at hardware.

It cannot tell you whether Bluetooth is switched on. That is the honest headline, and everything above follows from it. The only availability signal the platform gives a web page is about the adapter existing. For the on/off state, look at your system settings.

It cannot see devices you have not chosen. There is no list of what is around you, by design, and any page claiming to scan your surroundings without a chooser is describing something the API does not permit.

It cannot measure signal strength for an arbitrary device. Received power is only exposed through a separate scanning interface that is not broadly shipped and needs its own permission, so no distance or range estimate appears here.

It cannot pair, unpair, or repair anything. Pairing belongs to the operating system. A browser page can ask to talk to a device the OS already knows about and can report what happened, which is where this tool stops.

It cannot reach Classic-only accessories in any useful way, for the reasons set out above, and it cannot read battery level, firmware version, or anything else that lives behind a service this page has not been granted.

Everything here runs in your browser. The checks read your own browser’s API surface, the device identifier is issued locally by the browser and is not uploaded, and nothing is stored between visits.