How it works
From your screen to your downloads folder
Five steps, none of which involve a server. Here is what the page is doing at each one.
- 01
You choose your inputs
Decide whether to record your microphone and camera, and which ones if you have several. You can test the microphone here too. None of that touches your hardware yet: the browser stays silent and every device remains closed until you press start.
- 02
The browser asks what to share
Pressing start calls getDisplayMedia(). Your browser opens its own picker — screen, window or tab — which the page cannot skip, style or preselect. Recording begins the moment you confirm. Microphone and camera prompts follow only if you enabled them.
- 03
Frames are assembled in the page
Without a webcam, the screen track is recorded as-is. With a webcam, each frame is drawn to a canvas with the camera composited on top, and that canvas becomes the video track. Multiple audio sources are mixed into one track through a Web Audio graph.
- 04
MediaRecorder encodes to memory
The encoder emits a chunk roughly once a second. Chunks are pushed into an array in the tab. Pausing pauses the encoder, so the file stays continuous and the timer stays accurate.
- 05
You preview, then download or delete
Stopping joins the chunks into a Blob and creates an object URL for the preview player. Download saves that Blob to your device. Delete revokes the URL and releases the reference, at which point the tab is free to hand that memory back.
- 01
Screen, window or tab
You pick the source in the browser
- 02
getDisplayMedia()
Browser hands over a MediaStream
- 03
MediaRecorder
Encodes to WebM in the page
- 04
Blob in memory
Chunks held in the tab, nowhere else
- 05
Your downloads folder
Saved only when you click download
Receive no video, audio or frames
They serve the page itself. There is no upload endpoint to send a recording to.
Browser limitations
What browsers will and won’t do
Screen capture is one of the least consistent areas of the web platform. Rather than pretending otherwise, here is what changes between browsers and why.
System audio is not universal
Sound from the captured source is a Chromium privilege: a shared tab carries its audio, and Windows additionally allows a whole display to be captured with sound. Apple exposes no such route, and Gecko implements none. Only the microphone path behaves identically everywhere.
File format depends on the browser
Chrome, Edge and Firefox record WebM, usually VP9 or VP8 with Opus audio. Safari records MP4 with H.264 and AAC. The recorder queries MediaRecorder.isTypeSupported() and uses the first supported option, so the format you get is the one your browser can actually produce.
Mobile browsers cannot capture the screen
iOS and Android browsers do not implement getDisplayMedia() for capturing the device screen. This site is usable on a phone, but recording needs a desktop browser. Your operating system has a built-in screen recorder for mobile.
The source picker belongs to the browser
The page cannot choose or even see what you share until you pick it. The browser decides which screens, windows and tabs to offer. Some platforms also require an operating-system permission for screen recording before any source appears at all — on macOS that lives in System Settings, under Privacy & Security.
Long recordings use memory
Everything captured accumulates in the tab rather than on disk, so a marathon session at high resolution eventually competes with the rest of your machine for memory. Break long work into shorter takes.
Background tabs and the webcam overlay
Compositing a webcam needs the page to draw frames. Where the browser supports requestVideoFrameCallback, which Chrome, Edge and Safari do, drawing continues while the tab is in the background. Elsewhere it falls back to animation frames, which browsers throttle in hidden tabs. Screen-only recording is unaffected either way.
By browser
By platform