What Is WebADB? How ADB Works in a Browser With WebUSB

WebADB is the idea of running the Android Debug Bridge protocol directly inside a web browser, with no desktop program in between. It works because modern Chromium-based browsers can talk to USB devices through the WebUSB API, and ADB is just a protocol that travels over USB. A web page can therefore connect to your phone, ask you for permission, and then act as the ADB client itself.

A quick look at how ADB works

Classic ADB has three parts:

• The client is the adb command you type in a terminal.
• The server is a background process on your computer. It starts the first time you run a command, listens on a local port (5037 by default) and manages the connection to every device.
• The daemon, adbd, runs on the Android device itself and executes whatever the server asks: installing packages, opening a shell, transferring files, streaming logs.

When you type adb devices, the client asks the server, and the server talks to adbd over USB or TCP/IP. The server also handles the RSA key exchange that decides whether the phone trusts your computer. If you want to set up the phone side first, see how to enable USB debugging.

What WebUSB is

WebUSB is a browser API that lets a web page communicate with USB devices. A page cannot see every device plugged into your computer. Instead it calls the browser, which shows a chooser window listing compatible devices. You pick one, and only then does the page get access to it.

For an Android phone, the interesting part is that when USB debugging is on, the phone exposes a USB interface dedicated to ADB. A page that has been granted access to the phone can claim that interface and send and receive raw bytes on it.

How a browser speaks the ADB protocol

ADB's wire protocol is documented and fairly small: messages with a command, two arguments and a payload, covering things like connecting, opening a stream, writing data and closing. A WebADB library implements the same behavior as the adb client and server, but in JavaScript or TypeScript:

1. The page asks the browser to open the USB chooser.
2. You select the phone and the browser grants access.
3. The page claims the ADB interface and sends a connect message.
4. The phone answers with an authentication challenge.
5. The page signs it with an RSA key stored in the browser. The first time, the phone shows the Allow USB debugging? prompt with that key's fingerprint.
6. After you tap Allow, the session opens and the page can run shell commands, push files, install APKs or read logs.

In effect the browser tab replaces both the adb client and the adb server. ADBKit works this way: the workspace is an ordinary web page that connects to the phone over WebUSB.

Requirements and browser support

• A Chromium-based desktop browser, such as Google Chrome or Microsoft Edge.
• HTTPS. WebUSB only works in a secure context, so the page must be served over HTTPS (or from localhost during development).
• A user gesture. The chooser can only be opened by a click or tap, never silently in the background.
• USB debugging enabled on the phone, and a data-capable cable.

Firefox and Safari do not support WebUSB, so WebADB tools do not work there. Browser support on Android phones differs from desktop and is not a reliable way to control another device.

The security model

Giving a web page access to your phone sounds risky, so the platform layers several protections:

• Per-device permission. The page cannot enumerate your USB devices. You must choose the specific device in the browser's chooser window each time permission is not yet remembered.
• The ADB authorization. The phone independently asks you to approve the computer's RSA key. Without that tap on the phone, the connection stays unauthorized.
• Secure origin. Because HTTPS is required, the page you are talking to is authenticated and its code cannot be tampered with in transit.
• Revocable. You can remove a site's USB permission in the browser settings, and you can wipe the phone-side list with Revoke USB debugging authorizations in Developer options.

Note: As with any tool that controls a device, only open WebADB pages you trust. In ADBKit's case the device screen, files, logs and APKs go only between the browser and the device, and there is no ADBKit server that receives them.

Limits to know about

• One program at a time. A USB interface can be claimed by only one program. If Android Studio, scrcpy, another browser tab or a running adb server already holds the phone, the browser cannot open it. Close the other program or run adb kill-server. See fixing ADB device busy or unauthorized errors.
• No raw TCP in a browser. Web pages cannot open arbitrary TCP sockets, so connecting over Wi-Fi needs a small local relay on your computer. ADBKit provides one for this purpose.
• Browser support. Only Chromium-based desktop browsers work today.
• Performance depends on the cable and port. A poor cable or hub shows up as lag or disconnects.

Why it matters

For many tasks, WebADB removes setup: no platform tools to download, no PATH to configure, no drivers to match on macOS or Linux. You open a page, pick the device and start working. You can see what that looks like in practice in controlling an Android phone from your browser. For classic command-line work, ADB on the desktop is still a fine choice, and the two approaches speak the same protocol to the same daemon on the phone.