desktest.net
guide

USB Device Test Guide

A reference for the desktest.net USB Device Test. Browsers cannot scan your bus for arbitrary hardware: WebUSB and WebHID only expose devices you explicitly authorize through a native browser chooser. This guide covers what the chooser shows, what the tool reads back, and how to fix every failure mode.

Open the USB Device Test ->

What does the USB Device Test check?

The tool exercises the two web platform APIs that let a page talk to USB hardware: WebUSB (navigator.usb) and WebHID (navigator.hid). Three steps run in order:

  1. API support. Feature-detects navigator.usb and navigator.hid and confirms each exposes a requestDevice function. If neither is present, the run stops here.
  2. Interactive chooser. You click Request a USB device or Request an HID device. The browser calls requestDevice({filters: []}) and shows its native picker. You select a device; the page reads back vendorId, productId, productName, and the rest of the descriptor. You can pick more than one; each click opens a fresh chooser.
  3. Paired device list. Calls navigator.usb.getDevices() and navigator.hid.getDevices(). These return devices already paired with this origin. Your picks from step 2 should appear here too.

Nothing is sent off the workstation. The page only reads descriptor fields the browser already negotiated when the device enumerated.

When should I run this?

Reading the results

Each step renders a row with a status badge: Pending (grey), Running (yellow), Pass (green), or Fail (red). Failed rows expand to show the diagnosis and a numbered fix block.

For each device you authorize, the page shows a card with the key descriptor fields:

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, every authorized device, paired device list, per-step diagnoses) to the clipboard. Paste it into a ticket.

Common failures and fixes

Every failure path in the tool has a named diagnosis. Here they are in the order steps run.

webusb-not-supported: navigator.usb is missing

The page asked for navigator.usb.requestDevice and got undefined. This browser does not ship WebUSB.

  1. You are almost certainly on Firefox or Safari. Neither has implemented WebUSB and there are no plans on either roadmap as of 2026.
  2. Switch to Chrome, Edge, Opera, or another Chromium-based browser. Reopen the page and re-run.
  3. WebUSB also requires a secure context: HTTPS or localhost. A self-signed origin without a trusted cert will not get navigator.usb either. desktest.net serves HTTPS, so this only matters if you self-host the diagnostic.

webhid-not-supported: navigator.hid is missing

Same root cause as above, applied to the HID API. Firefox and Safari ship neither WebUSB nor WebHID; Chromium-family browsers ship both. Switch to Chrome, Edge, or Opera and re-run. Same HTTPS / localhost requirement applies.

both-apis-missing: neither API is available

Reported in step 1 when neither navigator.usb nor navigator.hid is defined. Two realistic causes:

  1. Browser does not implement them. Firefox and Safari (current and recent past releases). Switch to a Chromium-based browser.
  2. Enterprise policy disables them. Chrome and Edge both honor the DefaultWebUsbGuardSetting and DefaultWebHidGuardSetting policies. If IT pushed value 2 ("block on every site"), neither API will appear. Ask whoever manages the GPO whether desktest.net or the workstation's loopback origin is on the allowlist.
  3. Very old Chromium release. WebUSB landed in Chrome 61 (2017) and WebHID in Chrome 89 (2021). Anything modern has both. If you are on a frozen kiosk image, check the version.

user-cancel: chooser was dismissed

You clicked the request button, the browser dialog appeared, and you closed it without picking a device. Or you clicked Done before picking anything. This is not a failure of the device; the diagnostic just has nothing to report.

  1. Click Reset, run again, and select a device in the chooser before clicking Done.
  2. If the chooser is empty, the browser cannot see the device. Confirm it is plugged in (replug it; listen for the chime). On Linux, WebUSB needs a udev rule giving the browser permission to claim the interface.
  3. WebUSB and WebHID list different devices. If the WebUSB chooser is empty, try the WebHID chooser, and vice versa. A signature pad or barcode scanner is far more likely to appear under WebHID.

device-claim-failed: device picked but descriptor read failed

You selected a device in the chooser and the browser threw SecurityError or NotAllowedError when the page tried to read its descriptor. The browser will not let this page touch this device right now.

Almost always: Windows has assigned the device to one driver or one application at a time, and somebody else holds the claim. Closing the competing tool releases it.

  1. Zebra Setup Utilities claims Zebra printers exclusively while running. Close it and retry.
  2. Vendor printer utilities (Brother iPrint, Epson Status Monitor, HP Smart) hold print devices. Close them.
  3. Payment terminal POS apps (Verifone Vault, Ingenico desktop, the in-store POS itself) hold the terminal. Close the POS or sign out of it.
  4. Topaz SigWeb claims a Topaz signature pad. If you are testing a Topaz pad through this generic tool, stop SigWeb (or use the Signature Pad Test instead).
  5. The browser itself, in another tab: unpair the device from the other origin in chrome://settings/content/usbDevices and chrome://settings/content/hidDevices.
  6. The Windows kernel driver: some devices use a vendor driver that does not release. Unplug, replug, and try again. If that fails, the device is not WebUSB-accessible on this workstation and you need the vendor's native software.

aborted: request was interrupted

The page navigated, was reloaded, or the OS killed the chooser before you picked. Re-run the diagnostic and finish the chooser interaction in one go.

For IT admins

You can pre-authorize WebUSB and WebHID devices for a fleet so users do not see the chooser at all. This is the right answer for known good hardware (the corporate barcode scanner model, the standard ID badge reader) on the known good origin.

Chrome and Edge support the policies:

Both accept JSON with vendor_id / product_id pairs scoped to a list of origins. Example: pre-authorize a Honeywell Voyager 1200g (vid 0x0C2E, pid 0x0B61) for the corporate scanner test page and your line-of-business POS:

[
  {
    "devices": [{ "vendor_id": 3118, "product_id": 2913 }],
    "urls": ["https://desktest.net", "https://pos.internal.example.com"]
  }
]

Push that as a GPO under Computer Configuration, Administrative Templates, Google Chrome (or Microsoft Edge). Devices on the allowlist are auto-granted; no per-user click. Useful for rolling out scanners across a fleet without coaching every cashier through the chooser.

The mirror policies DefaultWebUsbGuardSetting and DefaultWebHidGuardSetting control the default for everything else: 2 blocks all sites, 3 asks (the browser default). Setting both to 2 and using the allowlist policies is a workable lockdown stance for kiosks.

Safari has no equivalent. Safari ships neither API and has no policy to enable them. If Safari is the corporate browser standard, this page will fail step 1 on every workstation with both-apis-missing. That is expected, not a misconfiguration; the vendor app that needs USB will not work in Safari either.

Behind the scenes

The WebUSB chooser is a browser-rendered dialog, not a page-rendered one. The page calls requestDevice({filters: []}) and the browser draws the list. A page cannot read it, style it, or pre-select an entry; that is the user-gesture and user-consent boundary that lets the spec exist at all.

An empty filters array tells the browser to list every device it can show. Real production code usually narrows it: filters: [{ vendorId: 0x0C2E }] shows only Honeywell devices. The diagnostic intentionally passes no filter so you can see everything the browser will offer; if a device is missing here, no production filter will surface it either.

Devices claimed by the system kernel may not appear. On Windows, a device bound to a vendor driver (not WinUSB, not HID class) is invisible to WebUSB. The same device may still appear under WebHID if it exposes a HID interface, because the HID class driver multiplexes. This is why a scanner that "does not show up in WebUSB" almost always shows up in WebHID.

navigator.usb.getDevices() and navigator.hid.getDevices() return devices previously authorized for this origin. Pairing is per-origin: a device you authorized on desktest.net is not visible to your internal POS site without a separate authorization. Pairings persist in browser-managed storage and survive restarts; users revoke them at chrome://settings/content/usbDevices and chrome://settings/content/hidDevices.

HID devices identify themselves with a usagePage and usage code in each top-level collection. usagePage 0x01 with usage 0x06 is "Generic Desktop, Keyboard" (typical barcode scanner). usagePage 0x0D is "Digitizer" (signature pads, drawing tablets). The collection count shown on each WebHID card is your hint at how the device describes itself; a device with three collections is usually a composite (keyboard + consumer controls + vendor).

No vendor IDs, product IDs, serial numbers, or anything else leaves the browser. The Copy Diagnostic Report button puts the data on your clipboard for you to paste into a ticket.