The install you did not need
Screen recorders are among the most over-built pieces of software on any machine. A tool whose entire job is capturing frames and writing a file routinely demands administrator rights, installs a background service, ships a tray icon, and — in several popular cases — bundles crash reporting and analytics. For a one-off "let me show you this bug" that is a ridiculous trade.
The browser already has the capability. It has had it for years, standardised as part of the WebRTC media specification. The reason you do not see it by default is purely that no single page owns the permission prompt.
What happens when you press record
The Screen Recorder here is a thin, honest wrapper around three standard APIs:
getDisplayMedia()asks the operating system — not the page, not us — for permission. The OS shows its own dialog listing your screens and windows. That indirection is the security model: a web page can ask, but it cannot take.- The chosen surface arrives as a
MediaStreamof raw frames. A microphone track is attached in parallel if you asked for narration. No frame is uploaded anywhere; the stream is a local object handle. MediaRecorderconsumes the stream, encodes with the best codec the browser offers (it probes VP9, then VP8, then WebM, then MP4 and takes the first it gets), and emits chunks as they are produced.- Chunks are assembled into a single in-memory
Blob. On download it is handed to an object URL and saved to your disk. Closing the tab destroys it.
Three modes are available: Screen Only, Screen + Mic for narrated walkthroughs, and Camera Only for a talking-head clip. There is no watermark, no length cap enforced by us, and no account.
Why this is better than an installed recorder, not just smaller
- It cannot phone home. There is no process to update, no telemetry to opt out of, and no background service to audit. A local page with no server does not have anywhere to send a file.
- Permission is per-use and visible. The OS dialog names the exact window you picked. An extension with broad host permissions gives you no such clarity.
- It is portable. The same recorder is on any machine with a current browser. Nothing to install on the colleague's laptop when you are screensharing together.
Getting a good recording, in four decisions
The quality ceiling of browser capture is set before you press stop. Four choices do most of the work:
- Share a window, not the whole desktop. Compositing a full 4K desktop forces the GPU to copy every layer every frame; a single window is dramatically cheaper, and it keeps your notifications out of the footage.
- Hide what you do not want captured. Tab audio and other windows are frequently included in a desktop capture depending on the browser. Close them.
- Keep the source resolution sensible. 1080p is the sweet spot: legible text, a file that still sends over chat.
- Record a few seconds of silence before you speak. It gives the encoder a keyframe to work from and removes the clipped first syllable.
The honest limitations
Browser capture is not a replacement for a streaming encoder, and it is worth knowing where it stops:
- No system audio on most browsers. Chrome can capture a tab's audio; whole-system audio capture is not broadly available. Plan to narrate rather than to capture desktop playback.
- WebM first, not MP4. Browsers hand you VP9/Opus in a WebM container. That plays everywhere modern, but if you need an MP4 for a specific uploader, run the file through Video Converter on this site first — also local.
- Files live in RAM. A long recording held entirely in memory is fine for a few minutes; a multi-gigabyte session is not, since there is no streaming-to-disk path.
- Safari and mobile are restricted. Display capture support varies by browser, and the tool tells you plainly if the current browser cannot do it rather than failing silently.
For those use cases — a bug report, a 90-second product demo, a lesson for a class — none of it matters. The recording is done before the installer would have finished.