Screen recording troubleshooting

The recording shows the wrong thing

You selected a single tab or window in the browser's share picker, and the recording stayed on that surface when you switched applications. The share surface is fixed once recording starts.

This is the most common failure and the most expensive, because it usually is not noticed until playback. What you saw on your own screen while recording is not what the recording captured — the recording only ever contained the surface you chose.

Screencast reads the surface back from the browser and shows a notice naming it in the first seconds: entire screen, a window, or a browser tab. Get into the habit of reading that notice before you start talking.

There is no fix after the fact. Stop, start again, and choose Entire Screen in the picker. Choose it by default for anything that moves between applications; choose a narrower surface only when the tighter framing is deliberate.

There is no sound in the recording

Check whether the browser's share dialog offered and enabled audio for the surface you selected. Enabling System audio in Screencast requests a shared-audio track but cannot make the browser provide one.

The Screencast toggle and the browser's audio control perform different jobs. Screencast requests audio; the browser and operating system decide whether the chosen tab, window, or screen can return it.

If it is microphone audio that is missing, check which input your operating system currently considers default. Connecting headphones, a monitor with a built-in microphone, or joining a call can change it silently.

Then check whether another application is holding the microphone. Video-conferencing tools frequently keep the device claimed after a call ends; quit the application rather than just leaving the meeting.

On macOS, whole-system audio is not consistently offered to browser capture. Sharing a browser tab with its audio enabled in a current Chromium browser is usually the more predictable route for web content.

The browser will not ask for permission

A previous denial is remembered. Clear it from the padlock or camera icon in the address bar, reload the page, and start again.

Once you deny screen, camera, or microphone access for a site, browsers generally stop asking and simply fail. Because the prompt never reappears, this looks like the recorder is broken rather than blocked.

Open the site settings from the icon at the left of the address bar, set the relevant permissions back to Ask or Allow, then reload. The prompt returns on the next attempt.

On macOS there is a second layer: the browser itself needs Screen Recording permission in System Settings under Privacy & Security. If no browser can capture your screen, this is almost always why, and it requires quitting and reopening the browser after you grant it.

The camera overlay froze or disappeared

Composed recordings depend on the browser continuing to deliver camera frames. Some browsers throttle that work heavily when the tab is not visible, and annotation makes the page more sensitive to it.

Screencast avoids the common animation-loop freeze by driving the composite from video frames rather than a page animation timer, which is why a plain Screen and camera recording generally survives being in the background. Annotations are the exception: keep Screencast visible while you draw so the overlay stays in sync with the video.

If the overlay stops mid-recording, Screencast tells you and the take cannot be repaired. Start a new recording rather than continuing, because everything after the failure will be missing the camera.

Reduce the load if this recurs. Recording a single window rather than an entire multi-monitor desktop, leaving the frame on Original, and closing other heavy tabs all cut the per-frame work substantially.

Export will not finish

Export WebM instead — it is the format the recording is already in, so it completes immediately and your work is safe. Then convert to MP4 separately if you need it.

MP4 is a separate conversion step. Screencast first tries a compatible WebCodecs encoder and then an in-page FFmpeg fallback. An encoder can be unavailable, reject the input, or fail to produce output; the saved WebM remains available in those cases.

Keep the tab open and in the foreground while a conversion runs. It is executing in that page; navigating away cancels it.

If the conversion completed but no file appeared, use Download MP4 again rather than re-converting. Screencast holds the finished file in the page, so a blocked download does not cost you the processing time.

Long recordings and limited available memory can make conversion harder. Closing other heavy tabs may help. A current Chrome or Edge release may expose a compatible WebCodecs path, but the browser can still use software encoding or fall back to FFmpeg.

The tab closed or the browser crashed mid-recording

Reopen Screencast. It looks for a saved recording on load and offers back either the completed video or the portion written before the interruption.

Because the video is written to browser storage in pieces as it records rather than held in memory until the end, an interrupted recording usually leaves a usable partial file. Annotations drawn during the recording are restored alongside it.

Recovery is per-browser and per-device. A recording made in Chrome will not appear in Firefox, and one made on your laptop will not appear on your desktop.

Private and incognito windows discard their storage when the window closes, so nothing is recoverable there. If a recording matters, do not make it in a private window.

If Screencast warned you about low storage before recording, expect recovery to be less reliable. That warning appears when under roughly 150 MB is free, which a long recording will exhaust.

The recording is choppy or the machine struggles

Reduce what has to be composed per frame: record a single window rather than every monitor, leave the frame on Original, and turn off background and padding unless you need them.

Screencast takes a shortcut when it can. A single source with the frame on Original, no background, no padding, and no annotation is passed straight through from the browser's capture track with no per-frame compositing at all. That is by a wide margin the cheapest way to record.

Every setting that changes the picture — a fixed aspect ratio, a background, padding, a camera overlay, annotations — turns on the compositor, which draws each frame. On a machine already under load, that is where dropped frames come from.

Close what you are not demonstrating. Other browser tabs playing video, a running build, and video-conferencing software are the usual competitors for the same resources the encoder needs.

Recording an entire multi-monitor desktop is the single most expensive option available, because the composed frame is as wide as all your displays combined. Share one display or one window instead.