You no longer need to install anything to record a short tutorial, a bug report or a walkthrough for a colleague. Desktop browsers can capture a tab, a window or a whole screen and turn it into a video file, through two standard APIs: getDisplayMedia, which opens the browser's own "choose what to share" dialog, and MediaRecorder, which encodes the result. The screen recorder is a thin layer over those two. This article explains what each choice actually captures, why sound is the part that most often goes missing, and how to predict the file size before you start.
The browser chooses, not the page
A web page cannot capture your screen on its own. It can only ask; the browser then shows a dialog, and you decide what to share. Two rules follow from that, both stated in MDN's getDisplayMedia reference:
- The request must come straight from a click or a key press (MDN calls it "transient user activation"). That is why a recorder cannot start by itself when the page loads.
- It only works on secure pages (https, or localhost while developing).
The dialog offers three kinds of surface. Which one you pick changes what ends up in the video:
| You share | What is recorded | Watch out for |
|---|---|---|
| A browser tab | That tab's page, even if you switch to another tab | Nothing outside the tab: no other apps, no browser menus |
| A window | That application window | Menus and dialogs that open as separate windows may be missing |
| Entire screen | Everything on that display, pointer included | Notifications, chat pop-ups and passwords you type elsewhere |
For a tutorial about a website, a tab is usually best: it ignores everything else on your desktop, and in Chromium browsers it can carry the tab's sound. Choose the entire screen only when you need to move between several applications, and switch on "do not disturb" first, because every notification that slides in is recorded.
The recorder asks the browser to hide its own tab from the list. Recording the recorder produces an endless "hall of mirrors" image, and MDN documents a selfBrowserSurface option for exactly this reason.
Why the sound is often missing
Video is always captured. Sound is offered only in some combinations, and the browser decides silently:
- Tab sound: Chrome and Edge offer an "Also share tab audio" switch when you pick a tab, on Windows, macOS, Linux and ChromeOS.
- Whole-screen (system) sound: Chromium browsers offer it when sharing the entire screen on Windows and ChromeOS. On macOS it depends on the browser version: developer reports say recent Chrome releases added it, so check the dialog on your own machine rather than assuming.
- Firefox and Safari: in developer tests the shared stream carries no audio, even when the page asks for it.
MDN is explicit that the systemAudio setting is only a hint: the stream "might contain no audio track even when audio is true". That is why the screen recorder tells you, while you record, whether tab or system sound and the microphone are actually in the recording. If shared sound is not available, add your microphone; the tool mixes it with any shared sound into the single audio track a recording can hold.
A worked example: how big will it be?
The recorder asks for a target video bit rate and 128 kbit/s for sound. Screen content is encoded at a variable rate, so the target works as a ceiling: a still slide costs very little, while scrolling or a playing video comes close to it. Ceilings for a 10-minute recording:
- Standard (2.5 Mbit/s video + 128 kbit/s sound): 2,628,000 bits × 600 seconds ÷ 8 = 197,100,000 bytes, about 197 MB.
- Small file (1 Mbit/s, no sound): 1,000,000 × 600 ÷ 8 = 75,000,000 bytes, 75 MB.
- Sharp text (5 Mbit/s + sound): 5,128,000 × 600 ÷ 8 = 384,600,000 bytes, about 385 MB.
A 10-minute slide presentation at the standard setting will usually come out far below 197 MB, because most frames repeat the previous one. Pick "sharp text" when viewers must read small code or spreadsheet cells; for a talking-head walkthrough of a slide deck, "small file" is plenty.
The whole recording is held in the browser's memory until you download it, which is why the recorder stops on its own after 60 minutes. For longer sessions, record in parts.
Formats you will get
Chrome, Edge and Firefox produce WebM (VP9 or VP8 video with Opus sound); Safari produces MP4 with H.264. The file is named to match. Every current browser and VLC play WebM. If a video editor refuses it, convert the file there or with a desktop converter.
On phones and tablets
According to the compatibility data on caniuse.com, getDisplayMedia is not available in Chrome for Android, Firefox for Android or Safari on iOS. No web page can record a phone screen. Use the system's own recorder instead: Android's quick settings tile, or Screen Recording in the iPhone and iPad Control Centre. The screen recorder says so instead of failing silently when it detects a phone.
Common mistakes
- Sharing the entire screen for a one-tab demo. Notifications, other tabs and private documents end up in the video.
- Assuming there is sound. Check the "tab or system audio" line in the panel during the first seconds, or record five seconds and play them back.
- A black video on a Mac. macOS must allow the browser to record the screen (Privacy and Security, Screen and System Audio Recording), and the browser must be restarted afterwards.
- Forgetting the browser's "Stop sharing" bar. It ends the recording too; the tool finishes the file instead of losing it, but your take ends there.
- Closing the tab before downloading. The video exists only in the page's memory.
- Recording your voice through the laptop speakers. If the tab's sound plays out loud while your microphone is on, it is recorded twice. Use headphones.
Tidy up before you share
A screen recording often shows more than you meant to. Grab a still of anything sensitive and blur it with the blur and redact tool before posting a screenshot, and record clean narration separately with the voice recorder if the laptop fan is loud. If you send several clips at once, the ZIP tool bundles them into one file.