Checking browser support…
See the phone's screen live in a tab, or record it to a video file — both over the USB cable.
Frames are decoded in this tab and a recording streams straight to your disk. Nothing is uploaded, and the staging file on the phone is deleted as soon as it has been copied.
Checking browser support…
Plug an Android phone into a Chromium browser over USB and this page does two different things with its display. Mirroring streams the screen as H.264 and decodes it in the tab, so you watch the phone in a window with a few tens of milliseconds of lag. Recording asks the phone's own encoder for an MP4 and streams that file straight to your disk. Nothing is installed on the phone and nothing is uploaded. One honest caveat up front: mirroring needs the scrcpy server binary, which is Apache-2.0 licensed and is **not** bundled in this static build — when it is absent the page says so plainly instead of pretending, and the recorder works either way, because recording needs nothing but the screenrecord binary that ships with Android.
scrcpy is not a screen-sharing app; it is a protocol and a small server that the client pushes to the phone and runs as the shell user. That server captures the display through SurfaceFlinger, encodes it with the phone's hardware H.264 encoder, and writes the stream back over an ADB socket. The client's job is only to decode and draw — which is why a browser can be one at all. The decode here is VideoDecoder from WebCodecs, fed the same stream the desktop client gets, rendering into a canvas. Control (touches and keys going the other way) is part of the same protocol and is wired, so a mirror that starts is also a mirror you can click.
A phone screen at 60 fps is far more data than a JavaScript decoder can keep up with, so mirroring is not "slow" without hardware decoding — it is not viable. That is why this page probes VideoDecoder support after it mounts and, when the answer is no, says so instead of offering a button that produces a black rectangle. Firefox and Safari are the usual answer of no; a Chromium browser on a desktop is the usual yes. Recording is unaffected by all of this: the encoding happens on the phone, and your browser only has to write bytes to a file.
They look adjacent and behave nothing alike. A mirror is live and keeps nothing — there is no file, and closing the tab leaves no trace on either machine; it is the right tool for a demo, for watching a device on a shelf, or for tapping through something with a keyboard. A recording is a file with a definite start and end, made by the phone rather than by us, and it is the right tool for a bug report or a store listing. The recorder here picks the destination on your disk *before* it starts, because the File System Access picker needs a click and the bytes arrive minutes later; the video then streams from the phone into that file in small chunks, so a 2 GB capture never sits in the tab's memory. The staging file on the phone is deleted as soon as it has been copied, and a recording left behind by an unplugged cable is cleared before the next one starts.
The recorder's limits belong to the platform, and it is better to read them here than to discover them in the file. There is no audio — screenrecord captures video only and has no flag for sound; the system recorder built into Android 11 and later can, but that is a different program. Its documented default and maximum is 180 seconds for one recording; some builds allow more, and when a device refuses, its own words are what this page shows. DRM-protected video comes out as a black rectangle, because the compositor will not hand those frames to an encoder — the same reason a screenshot of them is black. The frame size is fixed when recording starts, so rotating the phone part-way through letterboxes the rest. And an arbitrary --size is a request, not a guarantee: the AVC encoder may refuse a resolution it does not support, which is why the sizes offered here are ones encoders generally accept.
Neither half of this page is a substitute for a phone in your hand. Mirroring adds latency you can feel in a rhythm game, and a recording made at 4 Mbps will show compression artefacts on fast motion that were not on the screen. What both are good for is showing somebody else exactly what happened. From here, the logcat viewer shows what the phone was saying while you captured, the system monitor shows what its CPU and thermals were doing, and the Web ADB hub has the rest of the toolkit.
Tens of milliseconds on a good USB link — encode on the phone, transfer, decode and paint here — which is fine for demos, walkthroughs and clicking through an app, and not fine for anything where timing is the point. The number depends on the phone's encoder, the cable and how busy your machine is, and it is not something this page can fix from the browser side. If you need frame-accurate timing, record instead: a recording is made on the phone at the phone's own pace, so latency stops mattering.
Control is part of the scrcpy protocol and is wired here, so when a mirror is running, clicks and keystrokes in the canvas are sent back to the device. It is worth knowing what that is not: it is not remote access over the internet, and it is not root — the input is injected by the same `shell`-user server that captures the screen, so anything the shell cannot do here, it still cannot do. Recording is one-way by nature; there is nothing to control while a file is being written.
`screenrecord` documents 180 seconds as both its default and its maximum for a single recording, so that is the ceiling this page offers. Some builds raise it, and if yours refuses a value it is the device's own message you will see rather than a guess of ours. Size is the other limit to keep in mind: at the 20 Mbps default a three-minute clip is about 450 MB, and the panel shows the ceiling for your settings before you start, because it is the phone's own storage that holds the file until it has been copied to your disk.
Two independent reasons, and the page tells you which one applies. Mirroring needs WebCodecs hardware H.264 decoding, which Chromium desktop browsers have and Firefox and Safari do not — without it a software decoder could not keep up with a phone display, so the page says no rather than showing you a stuttering black window. Mirroring also needs the scrcpy server binary, which is not bundled in this build; when it is missing the page says exactly that. Recording depends on neither, and needs only the File System Access API to stream the file to your disk.
Device dashboard, shell drawer and every other Web ADB tool.
Watch the log while you reproduce whatever you are recording.
What the phone's CPU and thermals were doing during the capture.