Checking browser support…
Talk ADB to your Android over USB from the browser — device info, files, APK sideload, live logcat and a shell.
Talks to your Android over USB locally — nothing is uploaded to any server.
Checking browser support…
Web ADB Toolkit plugs your Android phone into the browser over WebUSB and speaks the ADB protocol directly — no Android SDK, no platform-tools, no adb binary to install. It stands on ya-webadb (yume-chan, MIT), the same engine behind web-based scrcpy, and wraps it in an instrument-style panel: pull a full device-info dump (model, Android version, serial, screen resolution, battery and installed-package count), browse and transfer files over the sync protocol, sideload an APK by dragging it in, watch logcat live with tag/level/regex filters, and run adb shell in a real terminal.
USB ADB works great in Chrome and Edge. Wireless ADB does not, and no web page can fix that: a browser has no raw TCP socket, so adb connect 192.168.x.x:5555 is simply impossible from a web app (the Direct Sockets API is reserved for installed Isolated Web Apps). What this tool can do instead is flip your phone into wireless mode for you: connect once over USB, click Enable wireless debugging, and it runs adb tcpip 5555 on the device. From then on you connect from your desktop adb over Wi-Fi. The web page is the enabler, not the wireless client.
On Windows, WebUSB often can't grab the phone's ADB interface until you replace its driver with WinUSB using Zadig — this is the single biggest reason web ADB fails on Windows, and the tool detects Windows and walks you through it step by step if a connection fails. macOS, Linux and ChromeOS need none of this; if you have one nearby, it just works. This all runs locally: your phone talks to your browser and nothing is uploaded to any server.
Analyze an APK first in the APK Analyzer, then jump here to install it on a real device — the two tools form a loop: inspect, then sideload.
No — and be wary of any web tool that claims otherwise. Browsers have no raw TCP socket, so a web page cannot open `adb connect 192.168.x.x:5555`. This tool connects over USB only. What it can do is enable wireless debugging for you: connect over USB once, click the button, and it runs `adb tcpip 5555` on the phone so you can then connect from your desktop `adb` over Wi-Fi.
Plug the phone in over USB, connect and approve the on-screen prompt, then click Enable wireless debugging. The tool runs `adb tcpip 5555`, which switches the phone's ADB daemon to listen on TCP port 5555. Find the phone's IP in Settings, then on your computer run `adb connect <phone-ip>:5555`. The browser cannot make that final connection itself.
Chrome and Edge on desktop (and Chrome on Android 148+), because WebUSB is a Chromium-only API. Firefox and Safari do not implement WebUSB and have no announced plans to, so they cannot open an ADB connection at all. The page still loads there and explains why, but the ADB features are unavailable.
On Windows the phone's ADB interface usually needs the WinUSB driver, installed with a free tool called Zadig. If connecting fails, the toolkit shows step-by-step instructions: run Zadig, enable List All Devices, pick the ADB interface, and replace its driver with WinUSB. macOS, Linux and ChromeOS don't need any driver and give a smoother experience.
No. Everything runs in your browser and talks to the phone directly over USB. APKs you sideload, files you transfer, logcat and shell output never leave your machine — there is no server in the path.
There is an experimental screen-mirroring section that uses the scrcpy protocol with WebCodecs H.264 decoding. It is the heaviest feature and depends on your browser supporting hardware H.264 decode; where that is unavailable the panel says so instead of breaking. The core panel — device info, files, APK install, logcat and shell — works without it.
Inspect an APK's permissions and signatures, then sideload it here →