Hardware
TesterBluetooth Signal Tester
Scan and connect to nearby BLE devices in your browser via Web Bluetooth. Read GATT services and characteristics, monitor RSSI signal strength.
Have feedback? Report bugs, suggest features, or share your thoughts — we read them allAbout Bluetooth Signal Tester
Test Bluetooth Low Energy (BLE) devices directly in your browser using the Web Bluetooth API. Scan for nearby devices, connect to them, read GATT services and characteristics, and monitor signal strength (RSSI) when available. Perfect for IoT developers, Bluetooth debugging, and hardware testing.
How to use:
- Click 'Scan for devices' to discover nearby Bluetooth Low Energy devices.
- Select a device from the browser's device picker dialog.
- View device information, including name, ID, and connection status.
- Explore GATT services and characteristics available on the connected device.
- Monitor signal strength (RSSI) as a best-effort value: it relies on watchAdvertisements(), which is separate from the requestLEScan() Scanning API and may stay unavailable without an experimental flag, so do not treat the live bar as guaranteed.
- Export the connected-device report as JSON or CSV, or copy it to the clipboard, to attach a reproducible BLE inventory to a QA bug ticket.
- Use 'Disconnect' to close the connection when finished.
Browser Compatibility
- Chrome 56+ and Edge 79+ (Desktop & Android): full support
- Opera and ChromeOS: supported
- Safari and Firefox: not supported (no Web Bluetooth)
- Android in-app browsers (Facebook, Instagram, TikTok WebView): blocked — open in standalone Chrome
- HTTPS / secure context required; http:// pages cannot scan
- Linux needs chrome://flags/#enable-web-bluetooth-new-permissions-backend plus the BlueZ stack
- Live RSSI is best-effort and may require experimental flags in Chrome
Technical References
- MDN Web Bluetooth API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API
- Web Bluetooth Specification: https://webbluetoothcg.github.io/web-bluetooth/
- Chrome Platform Status: https://chromestatus.com/feature/5264933985976320
Frequently Asked Questions
The tool uses the Web Bluetooth API to scan for nearby Bluetooth Low Energy (BLE) advertisements and connect to GATT (Generic Attribute) services on a chosen device. It reports the device name, the MAC-like identifier exposed by the browser, the list of advertised service UUIDs, and the Received Signal Strength Indicator (RSSI) in dBm when the platform exposes it. Once connected, you can browse the service and characteristic tree, read static characteristics like Device Information (manufacturer, model, firmware version), and monitor live values such as battery level. It does not measure classic Bluetooth (BR/EDR) used by older headsets, because Web Bluetooth is BLE-only by specification. Treat it as a portable BLE inspector rather than a full protocol analyzer.
Pairing in the operating system only verifies that a handshake completed. It tells you nothing about signal quality, supported services, or whether the firmware advertises the right capabilities. By scanning and connecting through this tool you can confirm that a fitness tracker actually exposes the Heart Rate service before you debug an app, check that a beacon broadcasts the expected iBeacon or Eddystone UUID, or watch RSSI degrade as you walk away from a smart lock to estimate effective range. Testing also helps when a vendor app refuses to connect — if the device shows up here with the expected services, the problem is in the app or its permissions, not the radio. This separates hardware faults from software faults very quickly.
RSSI is reported in decibel-milliwatts (dBm) and is always negative for received signals. A rough field guide: −30 to −50 dBm is excellent, typically achieved when the devices are within a meter; −50 to −70 dBm is good and gives reliable connections for headphones, mice, and trackers; −70 to −85 dBm is marginal and you may see audio dropouts or notification gaps; below −90 dBm the connection will likely fail or stall. Remember that RSSI is logarithmic — a 10 dBm drop represents roughly 10× less received power. Walls, human bodies, microwaves, and 2.4 GHz Wi-Fi all attenuate or interfere. For battery-powered BLE peripherals, the receiver in the peripheral is often weaker than in your phone, so a "good" RSSI in this tool does not guarantee equally good reception in the other direction.
BLE signals at 2.4 GHz behave as electromagnetic waves with a wavelength of about 12.5 cm, so small position changes can move you between constructive and destructive multipath fringes — the same standing-wave pattern that causes Wi-Fi dead zones. RSSI variations of 5–10 dBm between adjacent positions are completely normal indoors. The tool also averages over a small window, and the radio in your phone may report quantized values (often integer dBm). To get a stable read, hold the devices still for a few seconds and average mentally over many samples, or move slowly while watching the trend. If the value jumps wildly between scans without anyone moving, the antenna may be obstructed by your hand (the "death grip" effect) or another 2.4 GHz source is hopping into and out of the active channels.
A GATT service is a logical grouping of related data items called characteristics. Each service has a 16-bit UUID for standard profiles (e.g. 0x180F for Battery Service, 0x180D for Heart Rate, 0x1800 for Generic Access) or a 128-bit UUID for vendor-specific services. Characteristics inside a service expose readable, writable, or notifiable values — battery level returns a single byte from 0 to 100, while heart rate returns a small frame with flags and BPM. Reading a characteristic gives you the current stored value; subscribing to notifications gives you live updates pushed by the peripheral. Encrypted characteristics require pairing before they will respond. If a characteristic returns mysterious binary data, look up its UUID on the Bluetooth SIG specification site to find the byte layout.
The Web Bluetooth API only exposes devices that are actively advertising during your scan window, are within range, and match any service filter you supplied. Many devices stop advertising once they are paired and connected to a host, so a Bluetooth speaker that is currently playing music from your phone will not show up. Classic Bluetooth devices (older headsets, keyboards using BR/EDR) never appear because Web Bluetooth is BLE-only. Some browsers also require you to grant a one-time per-device permission and may filter out devices already paired at the OS level. Try power-cycling the target device to force a fresh advertising burst, move closer to rule out range, and ensure the browser is Chrome, Edge, or Opera on a non-iOS platform — Safari and Firefox do not support Web Bluetooth as of writing.
BLE 5.0 introduced 2 Mbps PHY (twice the data rate), Long Range coded PHY (S=2 and S=8 forward error correction for ~4× range at lower throughput), and extended advertising payloads up to 255 bytes. BLE 5.1 added direction finding (AoA/AoD), 5.2 added LE Audio with LC3 codec and isochronous channels, and 5.3 refined connection robustness. The Web Bluetooth API abstracts away the PHY in use, so the tool itself cannot show whether your link is on 1M, 2M, or coded PHY — that information is only available from low-level sniffers like nRF Sniffer or Ellisys. What you can infer indirectly: stable connections at extreme range (>30 m line of sight) suggest coded PHY support, and the manufacturer data field in the advertising packet often hints at the BLE version through its content layout.
Nothing is uploaded. The entire scan, connection, RSSI reading and GATT browsing run locally in your browser through the Web Bluetooth API — no device name, ID, service UUID, characteristic value or RSSI sample is sent to our servers, and the export files (JSON/CSV) are generated on your machine and only saved where you choose. When you pick a device in the browser picker you grant a per-origin, per-device permission so the page can reconnect to that specific unit; it does not give the site blanket access to all your Bluetooth hardware. To review or revoke it in Chrome or Edge, open chrome://settings/content/bluetoothDevices (or click the tune/lock icon in the address bar → Site settings → Bluetooth devices) and remove this site's saved devices. Clearing site data for the origin also drops the grants. This is why a QA workstation can safely use the tool without leaking the firmware inventory of devices under test.
Web Bluetooth is a powerful capability — it can read and write to nearby radios — so the specification only exposes it in a secure context. That means the page must be served over HTTPS (or from localhost during development); on a plain http:// origin navigator.bluetooth is withheld and the Scan button stays disabled, which is the behaviour you will see if you open the tool over an insecure proxy. On top of that, the underlying platform must support the API: on Linux, Chrome gates Web Bluetooth behind the experimental flag chrome://flags/#enable-web-bluetooth-new-permissions-backend and requires the BlueZ stack to be installed and running, because the permissions backend there is still maturing. macOS, Windows, Android and ChromeOS work out of the box in Chrome/Edge. If the tool reports that Web Bluetooth is unsupported, check the secure-context requirement first, then your browser and OS, before assuming the adapter is faulty.
Once you are connected, three buttons become active next to Refresh: Export JSON, Export CSV and Copy report. Export JSON downloads a machine-diffable ble-report-<device>-<timestamp>.json containing the device name and ID, a capture timestamp, the full service/characteristic tree with each characteristic's UUID and properties (Read/Write/Notify/Indicate), every RSSI sample observed, and computed min/max/average RSSI — ideal for attaching to a Jira or GitHub ticket or for diffing two firmware builds. Export CSV produces a spreadsheet-friendly file with a metadata header, a service_uuid / characteristic_uuid / properties inventory, and a timestamped RSSI sample table, so a repair lab can paste pass/fail rows into a batch table. Copy report puts the same JSON on your clipboard for a quick paste into a chat or ticket. The bar next to RSSI is a normalised 0–100% quality reading derived from the raw dBm shown in the badge (−100 dBm ≈ 0%, −30 dBm ≈ 100%), so cite the dBm value, not the percentage, when comparing units.
No — treat every writable characteristic as potentially dangerous until you know its specification. Writing arbitrary bytes to a vendor-specific characteristic can change firmware settings, trigger a factory reset, unlock a door, push the device into device firmware update (DFU) mode, or in the worst case brick the device by overwriting a configuration block. Standard services from the Bluetooth SIG document their writable characteristics with strict byte layouts; vendor services often have no public documentation and reverse-engineering them is non-trivial. The safe workflow is: read everything first to understand current state, only write to characteristics you have documentation for, keep a backup of any settings you change, and never run write operations against medical, security, or industrial BLE devices that you do not own. The Bluetooth SIG also restricts certain operations on commercial products to authorized firmware.
CONNECTIVITY5
WUTOOLS