Record your screen — unlimited, no watermark.

Why a browser-based screen recorder matters

Every popular "free" desktop recorder — Loom, Snagit, Screencastify, Descript’s screen tool — routes your recording through their servers or their app for storage and rendering. That decision has three side effects worth naming: (1) your recording sits on someone else’s infrastructure with their retention policy, not yours; (2) the free tier is time-limited or feature-limited so you upgrade; (3) the recording software has to be installed, which means it can update itself and change what it captures without you noticing.

The browser has done screen capture natively since 2019 (the getDisplayMedia API in the MediaDevices spec). Nothing in the standard requires an upload — the video stream stays in the browser tab, MediaRecorder writes it to a Blob in memory, and the download button hands you a file. That’s the entire pipeline. No server, no account, no time limit.

You can verify this yourself: press F12 in your browser, switch to the Network tab, clear it, and record something. The list stays empty while you record. When you hit Stop, a file appears in your Downloads folder. Nothing else happened on the network.

The "free" trick in most screen recorders

What actually happens when you drop a recording into each tool:

Format guide — WebM vs MP4

The browser’s MediaRecorder API outputs WebM by default (VP9 or VP8 video + Opus audio — all patent-free open codecs). Some browsers offer MP4 as an alternate container. Which one to pick depends entirely on where the file is going.

Practical rule: if the recording is going straight into Slack, email, Google Drive, or a PowerPoint deck for a non-technical viewer, pick MP4. If it’s for YouTube or an embed on a page you control, WebM is smaller for the same quality.

Resolution, bitrate, and file size

Two settings dominate final file size: frame resolution (720p vs 1080p vs source-screen) and bitrate (how many bits per second of video — roughly, compression tightness). Rough sizing for a 5-minute recording of typical desktop UI:

For screen recordings specifically (not real-world video), you can drop bitrate lower than you’d think — big flat colors and text compress efficiently. A 720p code walkthrough at 1 Mbps still reads fine.

Audio matters more than resolution

The single biggest quality difference between a "produced-looking" recording and a "quick-cast" one is audio.

• Built-in laptop mic: the default. Fine for internal share; obviously that in anything client-facing.
• Wired earbuds with mic: the free upgrade. Puts the mic ~8 inches from your mouth instead of at arm’s length. Cuts room echo.
• USB podcast mic ($60-80): the "sounds like a produced video" line. Audio-Technica ATR2100 or similar. Worth it if screen recordings are recurring work.

Six ways to actually use this

1. Bug reports for a developer

Nothing beats "here’s exactly what I did and what happened, in 30 seconds." Record the window (smaller file, no other-app leaks), include mic to narrate. Send as MP4 for Slack/Jira compatibility. 1080p at 2 Mbps is plenty.

2. Async standup / work updates

Record your screen showing the ticket you’re working on, narrate for 2-3 minutes what’s done and what’s blocked. Send in a team channel. Beats a written standup because code + your voice come together.

3. Onboarding walkthroughs for new hires

Record each system’s flow once instead of running the same live Zoom walkthrough weekly. New hire watches on their own timing, replays the tricky parts. WebM for intranet hosting; MP4 for Google Drive.

4. Async sales demo instead of a live meeting

Record the product walkthrough once at real speed with narration explaining what the prospect is looking at. Attach to a follow-up email. Some prospects will watch on their own time who’d never have booked a demo call.

5. Course lessons / tutorial content

Higher bitrate (5-8 Mbps), 1080p, MP4 for max compatibility. Turn off notifications first (both OS and browser tab). Test audio levels on a 30-second sample before doing a 20-minute take.

6. Legal / compliance evidence

When you need to prove "this is what the interface actually did," a browser-recorded video is the honest record. Because nothing uploads, the recording can go with sensitive material (client dashboards, PHI-adjacent tools, financial dashboards) that a cloud tool would leak.

Pre-recording checklist

1. Close what shouldn’t be on camera. Sensitive tabs, personal Slack, unrelated windows. A tab bar full of client names is the fastest way to leak something.
2. Turn off notifications. Mac: Do Not Disturb. Windows: Focus Assist. A ping mid-take = re-take.
3. Set browser zoom to 100%. Recordings at 75% or 150% look weird on playback.
4. Do a 15-second test. Mic level, cursor visibility, screen capture actually working. Nothing worse than a 20-min take with no audio.
5. Prepare the click order. If it’s a specific flow demo, know exactly what you’re clicking before you hit Record.
6. Full screen or window? Window is smaller, keeps other apps private, but the viewer sees no OS chrome. Full screen shows your dock/clock. Pick per audience.

Common problems and fixes

• Audio out of sync with video — usually a bitrate problem. Drop resolution one step, or record without system audio. Close background CPU-heavy apps.
• Recording is choppy — either the browser tab is under-resourced (close other tabs) or the target is doing heavy animations. Record at 30fps instead of 60fps for desktop UI.
• File is huge for a short recording — you’re at 4K or high-frame-rate. Drop to 1080p 30fps unless the content actually needs more.
• Can’t hear system audio — check "share tab audio" or "share system audio" when the browser’s source picker appears. Chrome allows tab audio; Firefox and Safari have quirks with system audio.
• Cursor doesn’t show up — the browser API captures the composited output, so the cursor is normally included. If it’s missing, your recording is likely of a window that renders its own cursor (rare — some Electron apps).

How to prove nothing was uploaded

1. Open this tool page.
2. Press F12 to open DevTools.
3. Click the Network tab, then the ⛞ (clear) button.
4. Hit Record. Grant screen-capture permission.
5. Record 15-30 seconds of anything on screen.
6. Hit Stop. The download appears in your Downloads folder.
7. Look at the Network panel — no POST requests appear. The download itself is a local blob URL (starts with blob:), not a network fetch.

Try the same test on Loom or Screencastify and you’ll see the upload happen as the recording finishes (or during, for cloud tools). That single check separates the honest tools from the ones running server-side.

Frequently asked questions