DeskTest.net
GitHub

Bluetooth Test Guide

A reference for the DeskTest.net Bluetooth Test. The browser cannot scan the airwaves for arbitrary Bluetooth hardware: Web Bluetooth only exposes the one Low Energy device you explicitly pick in a native chooser. This guide covers what the chooser shows, what GATT lets the page read back, why Bluetooth audio is not covered, and how to fix every failure mode.

Open the Bluetooth Test →

What does the Bluetooth Test check?

The tool exercises Web Bluetooth (navigator.bluetooth), the web platform API that lets a page talk to a Bluetooth Low Energy (BLE) device over the GATT protocol. Three steps run in order:

  1. Support and radio. Feature-detects navigator.bluetooth, confirms the page is a secure context (HTTPS or localhost), and calls navigator.bluetooth.getAvailability() to check whether a Bluetooth radio is present. If the API is missing, the run stops with an honest "not supported" verdict.
  2. Pair and connect. You click Pick a Bluetooth device. The browser calls requestDevice({ acceptAllDevices: true, optionalServices: ['battery_service', 'device_information'] }) and shows its native chooser. You select a device; the page calls device.gatt.connect() and reads device.name.
  3. Discover and read. Calls getPrimaryServices() to list the services the origin was granted, then tries to read Battery Level (service 0x180F, characteristic 0x2A19) or Device Information (service 0x180A: manufacturer and model strings). A successful read proves two-way GATT works.

Nothing is sent off the workstation. The page only reads the GATT values the device offers, and it disconnects the GATT server as soon as the read finishes.

Why it cannot test Bluetooth headsets or speakers

This tool tests BLE GATT data devices only. Bluetooth audio - headsets, earbuds, and speakers - uses classic Bluetooth profiles (A2DP, HFP) that the operating system routes. The browser never sees them, and there is no Web Bluetooth path to them. A headset that works fine for calls will not appear in this tool's chooser, and that is expected, not a fault.

If you need to verify a headset or speaker, check it in the operating system's sound settings, or use the DeskTest.net Microphone Test and Speaker Test, which exercise whatever audio device the OS has selected - including a Bluetooth one - through the browser's audio APIs. Those tools test the audio path; this one tests the BLE data path. They are different transports.

When should I run this?

Reading the results

Each step renders a row with a status badge: Pending (gray), Running (yellow), Pass (green), Warn (yellow), or Fail (red). Rows expand to show detail and, on a failure, a numbered fix block.

For the device you connect, the page shows a card with the fields GATT exposes:

The verdict panel at the top summarizes the run with a likely cause and a recommended next step. Copy Diagnostic Report copies a plain-text report (user-agent, secure-context status, radio availability, the connected device, service list, per-step results) to the clipboard. Paste it into a ticket.

Common outcomes and fixes

Every path in the tool maps to a named outcome. Here they are in the order steps run.

not-supported: Web Bluetooth is missing

The page asked for navigator.bluetooth and got undefined. This is reported as a Warn, not a Fail, because it is a browser limitation rather than a workstation fault.

  1. You are almost certainly on Firefox or Safari. Neither implements Web Bluetooth, and neither has it on the roadmap as of 2026.
  2. Switch to Google Chrome or Microsoft Edge on desktop, or Chrome on Android. Reopen the page and re-run.
  3. Web Bluetooth also requires a secure context: HTTPS or localhost. DeskTest.net serves HTTPS, so this only matters if you self-host the diagnostic on a plain-HTTP origin.
  4. iOS does not support Web Bluetooth in Safari or in any browser (all iOS browsers use the WebKit engine). A dedicated native app is the only route there.

no-radio: no Bluetooth radio available

getAvailability() returned false. The browser supports Web Bluetooth, but there is no usable radio right now.

  1. Turn Bluetooth on in the operating system. On Windows: Settings → Bluetooth & devices. On macOS: System Settings → Bluetooth.
  2. On a desktop with no built-in Bluetooth, plug in a USB Bluetooth adapter and confirm the OS installed a driver for it.
  3. Check that Bluetooth is not disabled by a hardware switch, airplane mode, or a fleet management policy.
  4. Re-run once the OS shows Bluetooth as on.

user-cancel: no device selected

You opened the chooser and closed it without picking a device, or clicked Skip. Reported as a Warn - inconclusive, not a device fault.

  1. Put the device into pairing / advertising mode. Many BLE devices only advertise for a short window after you press a button.
  2. If the chooser is empty, the device is not advertising as BLE, or it is a classic-only device (most headsets and speakers) that Web Bluetooth cannot see.
  3. Move the device closer and away from USB 3.0 hubs and ports, which emit interference in the 2.4 GHz band BLE uses.
  4. Click Reset, run again, and select the device before closing the chooser.

gatt-failed / no-gatt: picked but did not connect

You selected a device but device.gatt.connect() failed or the device exposed no GATT server.

  1. Power-cycle the device and keep it within a couple of meters of the workstation.
  2. Make sure the device is not already connected to another host - a phone or a second PC. Many BLE devices allow only one active GATT connection at a time.
  3. If the OS previously bonded the device, remove it from the OS Bluetooth list and pair again through the chooser.
  4. Click Reset and run again.

blocked: the browser refused access

The browser threw SecurityError or NotAllowedError. Either the page is not a secure context, or a policy blocks Web Bluetooth, or the request did not originate from a genuine user gesture. On DeskTest.net the page is HTTPS and the request is behind a button, so this usually points at an enterprise policy - see below.

Connected, but nothing to read

A Warn on step 3 with a passing overall verdict. The device paired and GATT connected, but it did not expose the standard Battery (0x180F) or Device Information (0x180A) characteristics this generic tool reads. That is common for vendor devices, which use their own service UUIDs. The capability you care about - pairing and connecting over BLE - still works. To read a vendor-specific characteristic, use that vendor's web app with the exact UUID it expects.

For IT admins

Chrome and Edge gate Web Bluetooth with enterprise policies. If a fleet reports not-supported on Chromium browsers (rather than on Firefox/Safari), a policy is the likely cause.

If your BLE web app and this test both need to run, allowlist their origins and confirm DefaultWebBluetoothGuardSetting is not set to 2. Push the policy under Computer Configuration → Administrative Templates → Google Chrome (or Microsoft Edge).

Safari and Firefox have no equivalent - they ship no Web Bluetooth at all, and no policy turns it on. If Safari or Firefox is the corporate standard, this page will report not-supported on every workstation, and any BLE web app will fail there too. That is expected, not a misconfiguration.

For provisioning kiosks, remember that Bluetooth audio still works normally regardless of the Web Bluetooth policy - it is handled by the OS, not the browser, so a locked-down Web Bluetooth policy does not affect headsets or speakers.

Behind the scenes

The Web Bluetooth chooser is a browser-rendered dialog, not a page-rendered one. The page calls requestDevice() and the browser draws the device list from what it hears advertising nearby. A page cannot read that list, style it, or pre-select an entry; that is the user-gesture and user-consent boundary the spec is built on.

acceptAllDevices: true tells the browser to list every advertising BLE device. Production code usually narrows it with filters (for example filters: [{ services: ['battery_service'] }]). The diagnostic accepts all devices so you can see everything on offer; if a device is missing here, a production filter will not surface it either.

Service access is opt-in. Web Bluetooth only grants the page access to services named in the request. That is why the test lists battery_service and device_information in optionalServices: without them, getPrimaryServices() would refuse to return those services even if the device has them. A device's own vendor services are only reachable when the app requests those exact UUIDs.

The device address is hidden. Web Bluetooth never exposes the hardware Bluetooth MAC. Instead the browser assigns an opaque, per-origin device ID. The same physical device gets a different ID on a different origin, so sites cannot use it to track you across the web.

BLE, not classic. Web Bluetooth speaks only Bluetooth Low Energy and only the GATT profile. Classic Bluetooth profiles - audio (A2DP/HFP), serial port (SPP), file transfer - are entirely out of scope and handled by the operating system. A dual-mode device only appears if it is advertising as BLE.

One connection at a time. Most BLE peripherals accept a single active GATT connection. If a phone or another PC already holds it, the chooser may still list the device but connect() will fail. The test releases its GATT connection as soon as it has read what it needs, so it does not hold the device open.

No device names, service UUIDs, or read values leave the browser. The Copy Diagnostic Report button puts the data on your clipboard for you to paste into a ticket.

Elsewhere on the web: