Screencast browser compatibility and requirements

Which browsers work best with Screencast?

A current desktop version of Chrome or Edge gives you the most complete workflow: screen capture, camera overlay, shared audio where the operating system allows it, and local MP4 conversion.

Screencast is built entirely on browser capture APIs rather than a downloaded helper application. That is what lets it run without an install, and it is also why what you can record depends on the browser you open it in. There is no Screencast-side setting that can add a capability your browser does not expose.

Chrome and Edge share the same underlying engine and behave almost identically here. Firefox records screen and camera reliably and exports WebM without trouble, but its system-audio support in the screen-sharing picker is more limited, and MP4 export falls back to the slower in-browser encoder described below.

Safari is the most constrained of the desktop browsers. Screen capture works, but the combination of capture, camera compositing, and local MP4 conversion is not something we would rely on for an important recording. If Safari is your daily browser, it is still worth opening Screencast in Chrome for anything you only get one take at.

If a browser cannot support recording at all, Screencast tells you directly rather than failing silently part-way through: it checks for MediaRecorder and the screen-capture API before it asks for any permission, and shows a message naming Chrome, Edge, or Firefox as alternatives.

What actually differs between browsers?

Three things vary: which audio sources the share picker offers, which local MP4 conversion path is available, and how the browser labels the surface you chose to share.

Audio is the largest difference and the one that surprises people most often. Current desktop browsers generally support microphone capture after permission, but device policy or an unavailable input can still block it. Shared audio is less consistent. On Windows, Chrome and Edge commonly offer system audio for an entire screen and tab audio for a browser tab. On macOS, tab audio is generally the more predictable browser option.

MP4 export differs next. Screencast records to WebM first, then converts locally when you ask for MP4. If the browser exposes a compatible WebCodecs encoder, Screencast uses it and asks the browser to prefer hardware acceleration. The browser may still choose software. Otherwise, Screencast falls back to FFmpeg running in the page, which can take longer for large recordings. Screencast identifies the active path while it works.

Finally, browsers differ in how precisely they report what you picked. Screencast reads the share surface back from the browser and adjusts its on-screen notice accordingly, so you get a different message for an entire screen, a single window, and a browser tab. Where a browser reports the surface vaguely, that notice is correspondingly less specific.

Can Screencast record an iPhone or Android screen?

No. Mobile browsers do not implement the screen-capture API at all, so no browser-based recorder can capture a phone screen — this is a platform restriction rather than a Screencast limitation.

Both iOS and Android treat screen capture as a privileged operating-system function and do not expose it to web pages. Any site claiming to record your phone screen from a mobile browser is either recording only its own page or asking you to install something.

Use the recorder built into the operating system instead. On iPhone and iPad, add Screen Recording to Control Centre in Settings. On Android, the screen recorder lives in the quick-settings panel on most recent devices. Both save a video file you can then move wherever you need it.

Camera-only recording is a partial exception, since mobile browsers do expose the camera. It works in some mobile browsers, but the review-and-export step is built for a larger screen and we would not recommend depending on it.

What permissions does Screencast ask for, and when?

Only what you have switched on, and only at the moment you press record — the share picker for screen capture, and a separate camera or microphone prompt when those sources are enabled.

Nothing is requested when the page loads. Screencast asks your browser for a capture stream only after you choose Start recording, which is why you will not see a permission prompt while you are still setting up the frame, background, or camera layout.

The screen prompt is your browser's own share picker, not a Screencast dialog, and it is the point at which you decide what is actually visible in the recording. Screencast cannot pre-select a screen for you or see anything you do not choose there.

Camera and microphone are requested separately and only when the corresponding control is on. If you record in Screen mode with the microphone toggle off, no camera or microphone permission is requested at all.

If you previously denied a permission, the browser will usually not ask again — it will just fail. Clear the block from the padlock or camera icon in the address bar, reload, and try again.

Why does Screencast keep suggesting Entire Screen?

Because the share surface you choose is fixed for the whole recording. If you pick a single tab or window and later switch to another application, the recording keeps showing the original surface, not what you moved to.

This trips up more recordings than any other single setting. A demonstration that moves between a browser, a terminal, and a design tool has to be recorded as an entire screen; there is no way to widen the selection once recording has started.

Screencast reads back what you actually chose and shows a notice naming it, so you can catch the mistake in the first seconds rather than at the end. If the notice says you are recording a browser tab or a window and that is not what you intended, stop and start again before you have spent ten minutes on a take you cannot use.

Choose a narrower surface deliberately when the tighter framing is the point: a single tab keeps notifications, other monitors, and unrelated windows out of the video without any editing afterwards.

How do I check my setup before a recording that matters?

Do a fifteen-second dry run with the exact sources and settings you intend to use, then play it back and export it before you record the real thing.

Record a short take with the same mode, the same share surface, the same audio toggles, and the same frame and background settings. Most problems — a muted microphone, a system-audio box you did not tick, the wrong share surface, a camera overlay covering something important — are obvious within a few seconds of playback and invisible while you are recording.

Export the test file too, not just play it. Export is where browser differences show up: it tells you whether the browser uses the WebCodecs path or the FFmpeg fallback, which matters if the real recording will be long.

Check your free disk space if the recording will be long. Screencast writes the video to browser storage as it goes and warns you when less than roughly 150 MB is available, because a recording that runs out of space part-way through may not be fully recoverable.