Checking browser support…
Back up a whole camera roll over the USB cable, browse the phone's storage, and push files back — nothing installed on either end.
Files travel over the USB cable between your phone and this tab. Nothing is installed on the phone and nothing is uploaded anywhere.
Checking browser support…
Plug an Android phone into a Chromium browser over USB and this page reads its storage: the camera roll and the other media folders, grouped by the day each file was taken, with sizes and dates straight from the filesystem. Tick what you want and it is pulled to your computer as a ZIP that is written to disk while it is being built, or as individual files. The same page browses the rest of the phone one directory at a time and pushes files back the other way. Nothing is installed on the phone, nothing is uploaded — this is a static page talking to adbd over the cable, and closing the tab ends it.
When you plug a phone into a computer and pick "File transfer", you get MTP — a protocol designed for cameras in 2008, in which every file operation is a round trip through a database the phone maintains, and in which there are no real file handles. In practice that means the failures everyone recognizes: a folder that shows the wrong number of photos, a copy of 3 000 files that stops at 1 700 with no error, thumbnails that hang Explorer, videos that copy at a tenth of the speed of the same cable moving the same bytes over ADB, and a phone that has to be unplugged and replugged before the computer will see it again. ADB's sync protocol is a much smaller thing: open a stream, name a path, receive bytes. It reads the filesystem rather than a media database, so what it lists is what is there, and a failure names the file that failed instead of stopping the transfer.
Since Android 11 an *app* cannot read other apps' files in shared storage without a special permission, which is why so many file-manager and backup apps got worse. The ADB shell is not an app: it runs as the shell user, which holds broad read access to the primary shared volume, so /sdcard/DCIM, /sdcard/Pictures, /sdcard/Movies and /sdcard/Download are as readable over the cable as they ever were. That is why this page can exist at all. The one place scoped storage really did close a door is /sdcard/Android/data, an app's own private files — that is not what this page reads, and where the Storage Analyzer does look at it, it says plainly that shell access there varies by version and manufacturer.
A camera roll is tens of gigabytes. Any tool that offers to "download all as ZIP" by collecting the files in the browser first is quietly promising to hold all of them in the tab's memory, and it does not survive contact with a real phone. So the archive here is built the other way around: each photo is read from the phone in small chunks, each chunk goes straight into the archive encoder, and each encoded chunk goes straight into the file on your disk that you named before the transfer started. Peak memory is a couple of hundred kilobytes regardless of the total. Two consequences are visible in the interface. The archive is *stored*, not compressed — JPEG and H.264 are already compressed, and deflating them would spend the phone's time to gain a fraction of a percent. And because a classic ZIP stores sizes and offsets in 32-bit fields, a selection over about 4 GB is split into numbered parts rather than becoming an archive that unpacks on one machine and fails on the next; a single file too large for any archive is written beside them under its own name. Writing straight to disk needs the File System Access API, which is Chromium-only and asks for the destination on a click; without it the page saves one file at a time and says so, rather than building an archive in memory anyway.
There is no thumbnail on the phone that this page can use: Android keeps its own previews in an app-private cache the shell has no access to, and the sync protocol has no way to ask for part of a decoded image. A preview therefore means pulling the entire original — 3 to 5 MB for a 12 MP photo, over 10 MB for a 48 MP one — so a screen of twelve pictures is tens of megabytes across the cable. The album starts in data-saver mode with pictures off, loads at most three at a time when they scroll into view, never pre-fetches, keeps a bounded amount of decoded thumbnails in memory, and shows the running total of what previews have cost so far. HEIC files are listed but not previewed, because desktop browsers cannot decode them.
Nothing on this page deletes anything on the phone. Removal in this toolkit belongs to the Storage Analyzer, and only for targets one of its scanners found — there is no free-path delete here and no way to reach one. Pushing files *is* a change to the phone, so it goes through the same warning-tier confirmation the rest of the family uses, with the exact destination paths listed before anything is written. From here, the Web ADB hub has the device dashboard and the other tools, the Storage Analyzer shows what is filling the phone up, and the APK Installer sends software the other way.
Connect the phone with USB debugging enabled, let this page scan the media folders, then use "Everything since" to pick a date — or Select all — and press "Choose a folder and start". You choose a folder on your computer once, and the selection is written into it as one or more ZIP archives while the files are being read off the phone. Files that are too large for an archive are written into the same folder as plain files. If your browser has no File System Access API (anything other than Chrome, Edge or another Chromium browser), the page falls back to saving one file at a time, which works but is slower and has a size ceiling per file.
No, because the archive is never held in the browser. Each file is read from the phone in chunks, each chunk is fed straight into the ZIP encoder, and the encoder's output goes straight into the file on your disk — the tab holds a couple of hundred kilobytes at a time whether the backup is 600 MB or 60 GB. The one limit that is real is the ZIP format itself: a classic archive addresses 4 GiB, so a large selection is split into numbered parts, and a single file bigger than that is copied beside the archives under its own name rather than mangled into one.
The album view probes a fixed list of well-known media folders — DCIM/Camera, Screenshots, Pictures, Movies, Download and a handful of common messaging-app paths — and shows the ones that exist, because a recursive walk of the whole of `/sdcard` on a full phone is minutes of round trips. If a folder is not on that list, open it in the Browse tab, which lists any directory you type. `/sdcard/Android/data` is a different matter: it holds apps' private files, and how much of it the shell may read changed in Android 11 and varies by manufacturer, so this page does not pretend to cover it.
The files are on the volume; they are just not in MediaProvider's database yet, and gallery apps read the database rather than the filesystem. That is why a file manager finds them immediately and Photos does not. After a push this page broadcasts `MEDIA_SCANNER_SCAN_FILE` to nudge the scanner, and prints whatever the broadcast said — but that intent was deprecated in Android 10 and some manufacturers ignore it, so the honest options if it did not work are to open the file in a file manager (which usually triggers indexing), or reboot the phone, which rescans shared storage.
Device dashboard, shell drawer and every other Web ADB tool.
What is filling the phone, and how to free it up.
Install an APK, APKS, XAPK or APKM by dragging it in.
Live CPU, memory, thermals and I/O while a transfer runs.