TroubleshootingPublished: 7 min read

Android Device Not Showing in Chrome's USB Picker (WebUSB): Fixes

Android phone missing from Chrome's WebUSB device picker? Work through cable, USB debugging, USB mode, busy adb server, WinUSB driver, Linux udev rules and policy.

When an Android device is not showing in Chrome's USB picker, the cause is almost always one of six things: a charge-only cable, USB debugging switched off, a phone in "Charging only" USB mode, another program already holding the device, a Windows driver that is not WinUSB, or missing udev rules on Linux. Work through the checklist below in order; each step takes under a minute and the picker usually fills in before you reach the end. The steps apply to any WebUSB site, including the ADBKit workspace.

Step 1: Cable, port and unlock

  • Use a data cable. Many cables that ship with chargers carry power only. If the phone charges but the computer never chimes or shows a notification, swap the cable.
  • Plug into the computer directly. Hubs, monitors and docks sometimes fail to enumerate phones.
  • Unlock the phone and keep the screen on. Some devices do not expose the ADB interface until unlocked.

Step 2: USB debugging must be on

WebUSB only lists the ADB interface, and Android only exposes that interface when USB debugging is enabled. A phone with debugging off still appears as a camera or storage device to the operating system, but Chrome's picker will stay empty. Open Settings › Developer options and confirm USB debugging is on; if Developer options is missing, follow how to enable USB debugging on Android.

Step 3: Check the USB connection mode

Pull down the notification shade and tap the "Charging this device via USB" notification. Some phones, especially older Samsung, Huawei and Xiaomi models, only publish the ADB interface when the mode is File transfer / MTP rather than Charging only. Switch it and watch the picker.

Step 4: Another program is holding the device

An ADB interface can be claimed by one program at a time. If adb, Android Studio, scrcpy, Vysor or another ADBKit tab already has it, Chrome may still list the phone but fail to open it, or may not list it at all on Windows.

adb kill-server

Then close Android Studio and any mirroring tool, close other tabs that had the device open, and retry. Details are in fixing ADB device busy or unauthorized errors.

Step 5: Windows needs the WinUSB driver

On Windows, Chrome can only talk to a USB interface that is bound to the generic WinUSB driver. The Google USB Driver (installed through the Android SDK Manager) and most manufacturer drivers (Samsung, Xiaomi, OnePlus) bind the ADB interface to WinUSB, which is why adb and Chrome work side by side with them. Some older OEM packages install a vendor-specific driver instead, and then the device never appears in the picker.

To check:

  1. Open Device Manager with the phone plugged in and debugging on.
  2. Look under Android Device, Universal Serial Bus devices, Portable Devices, or a vendor section such as SAMSUNG Android Phone.
  3. Right-click the ADB interface entry, choose Properties › Driver, and read the provider. WinUSB or Google, Inc. are fine; a yellow warning icon or an unknown device means no driver is bound.

If the driver is missing or wrong, install the Google USB Driver or your manufacturer's current driver, then unplug and replug the phone. On Windows 11 the ADB interface is sometimes bound automatically with no driver install at all.

Warning: Zadig can force WinUSB onto any interface, and it does work for ADB. But choosing the wrong interface (for example the MTP storage interface) breaks file transfer in Windows Explorer until you roll the driver back. Treat it as a last resort, note the original driver first, and never run it on a device you cannot afford to reconfigure.

Step 6: Linux needs udev permission

Linux shows the phone to Chrome, but without permission Chrome cannot open it, so the picker lists it and then fails. Create a rules file giving your user access:

sudo nano /etc/udev/rules.d/51-android.rules

Add one line per vendor. For Google and Pixel devices (vendor 18d1):

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"

Find your vendor ID with lsusb (Samsung is 04e8, Xiaomi 2717, OnePlus 2a70). Then reload and reconnect:

sudo udevadm control --reload-rules
sudo udevadm trigger

Make sure your user is in the plugdev group (groups $USER). The android-udev or android-sdk-platform-tools-common package already includes these rules. Snap or Flatpak builds of Chrome may be sandboxed away from USB; Google's .deb is the safe choice.

Step 7: macOS, Chrome OS and virtual machines

macOS needs no driver, and devices appear as soon as debugging is on. If one does not, the usual suspects are the cable and a running adb server.

Chromebooks support WebUSB in Chrome, but a phone plugged into a Chromebook may be claimed by the Linux container or the Android subsystem first. Disconnect it from those and retry.

Virtual machines are the hardest case. Chrome inside a VM only sees a phone if the hypervisor passes the USB device through, and passthrough often drops the connection when Android re-enumerates after you tap Allow. Run the browser on the host if you can.

Step 8: Browser, HTTPS and policy

  • Firefox and Safari have no WebUSB. Use Chrome, Edge, Brave, Opera or another Chromium-based desktop browser. Mobile browsers are not supported either.
  • HTTPS is required. WebUSB is a secure-context API; a page served over plain http:// (other than localhost) cannot even show the picker.
  • Enterprise policy. On a managed computer, the DefaultWebUsbGuardSetting policy can block WebUSB entirely, and WebUsbBlockedForUrls / WebUsbAllowDevicesForUrls can restrict which sites and devices are permitted. Visit chrome://policy to see what is applied; only your administrator can change it.
  • Site permission. If you once clicked Block, Chrome remembers it. Click the lock icon in the address bar, open Site settings, and reset USB devices for the site.
  • Extensions. Privacy extensions occasionally break the picker. Test in an incognito window with extensions disabled.

When the phone appears but "Allow USB debugging" never shows

If the picker lists the phone, you select it, and the site then waits forever for authorization, the problem has moved from USB to ADB. The prompt is drawn by Android, so:

  1. Unlock the phone and keep the screen on; the prompt will not appear over a lock screen.
  2. Unplug and reconnect the cable, then connect again from the site.
  3. If it still does not show, open Developer options › Revoke USB debugging authorizations, reconnect, and watch for the prompt.
  4. A device reported as unauthorized by adb devices has the same cause: an answered-with-Deny or stale authorization. Revoking and reconnecting fixes it.

Tick Always allow from this computer so the prompt does not return every time.

How ADBKit's status messages map to these causes

ADBKit shows each stage of the connection, which points to the step above to revisit.

Message in ADBKitWhere to look
"This browser doesn't support WebUSB"Step 8: switch to a Chromium desktop browser
"Open this page over HTTPS or localhost"Step 8: the page is not a secure context
"No device was selected"The picker was empty or you closed it: Steps 1 to 6
"Browser permission to access the device was denied"Step 8: reset the site's USB permission
"The device is busy in another tab or application"Step 4: adb kill-server and close other tools
"Waiting for device authorization…" that never endsThe Allow prompt section above
"The device declined the authorization request"You tapped Deny; revoke authorizations and reconnect
"The connection to the device was lost"Step 1: cable or port dropped

To connect in ADBKit: open the workspace in Chrome or Edge, click Connect device, pick the phone in the USB picker, and tap Allow on the phone. The status line under the button moves from "Requesting browser permission" to "Opening device transport" to "Waiting for device authorization" to "Connected". Whichever stage it stops at points to the fix. ADBKit talks to the phone directly from the tab, so nothing about the connection goes through a server. For the technical background on how a browser speaks ADB, read what WebADB and WebUSB are, and for the full workflow once you are connected, see controlling Android from your browser.