How Screencast keeps screen recording local

What "local-first" means here, precisely

Your screen, camera, and microphone data is captured by your browser, held in browser storage, composed and encoded on your device, and written to your disk when you export. The current recorder has no upload step or application endpoint that receives the video.

This is a property of the implementation rather than a promise about an unseen cloud process. Screencast is delivered as a static web application. Its recording path writes MediaRecorder chunks to this site's IndexedDB database, and its export path creates a local browser download.

The practical consequence is that Screencast does not hold a cloud copy or a per-user recording history. Website analytics can still receive ordinary visit data, as described below, but the recorder does not send the captured media to that analytics service.

It also means the recording is only as safe as the device it is on. There is no cloud copy to fall back on if you clear your browser data, if the machine fails, or if you export nothing. Local-first shifts responsibility to you along with the control.

Where the recording actually lives while you record

In your browser's own storage on that device — written incrementally as the recording proceeds, so a long take is not held entirely in memory.

Screencast writes the video out in pieces as they arrive rather than accumulating the whole recording in memory and saving at the end. That is what makes long recordings practical, and it is also what makes partial recovery possible if something interrupts you.

Before recording starts, Screencast asks the browser to mark that storage as persistent and checks how much room is available. If less than roughly 150 MB is free, it warns you, because a recording that exhausts the quota part-way through may not be fully recoverable.

If you reload the page or the tab crashes, Screencast looks for a saved recording on the next visit and offers it back — either the completed video or the portion that had been written before the interruption. Annotations drawn during the recording are restored with it.

Private or incognito windows change this. Browser storage there is discarded when the window closes, and some configurations disable it entirely. Recording still works, but recovery does not, so treat a private window as a single-session tool.

What the website does measure

The site uses Google Analytics for ordinary visit information, subject to the consent settings described in the privacy policy. The recording media is not included in those analytics calls.

This is the important exception to the shorthand "nothing leaves your device". Analytics can report a page visit and browser or device information allowed by its configuration and your consent state. The app does not attach recording blobs, captured frames, microphone tracks, filenames, or recording duration to its analytics configuration.

The distinction worth holding onto is between the website and the recorder. The website is a normal website and behaves like one. The recorder is a local tool that happens to be delivered by that website.

Our privacy policy sets out the service used and the regional consent defaults. Browser privacy controls or a content blocker may also restrict analytics; those controls do not form part of the recording pipeline.

Your browser is the thing enforcing this

Screencast cannot see any screen, camera, or microphone you have not explicitly granted through your browser's own prompts, and the choice of what to share is made in the browser's dialog, not ours.

When you start a screen recording, the picker that appears belongs to your browser. Screencast cannot pre-select an option, cannot see the list of your open windows, and receives nothing but the single surface you chose.

Camera and microphone are requested separately and only when you have those sources switched on. Recording your screen with the microphone off involves no microphone permission at all.

You can stop an active screen share from the browser interface and manage camera or microphone access in the site-permission controls. The exact icon and wording vary by browser.

How to keep a recording you care about

Export it and move the file somewhere you actually back up. Browser storage is working space, not an archive.

Screencast keeps your most recent recording so you can come back to it, but that is convenience, not durability. Clearing browsing data, a browser storage-pressure eviction, a profile reset, or switching devices will all take it away without warning.

Export as soon as you know the take is good, and treat the exported file the way you treat any other important file — into your documents, a synced folder, or wherever your backups actually run.

Use Clear saved when you are finished, particularly on a shared or work machine. It removes the stored recording from that browser deliberately rather than leaving it for the next person or the next eviction.

When a local-first recorder is the wrong choice

When you need shared team libraries, automatic transcripts, viewer analytics, comment threads on the video, or a link you can send without sending a file.

Those are genuine features and they require a server by definition. A tool that keeps everything on your device cannot offer them, and it would be dishonest to imply otherwise.

Screencast is aimed at the large category of recordings that do not need any of that: a bug report, a walkthrough for one colleague, a demonstration attached to a ticket, a quick explanation instead of a long message. For those, a hosted library is overhead you pay for in accounts, uploads, and retention policies.

If your organisation requires that recordings never touch third-party infrastructure, the local-first model is the point rather than a limitation — but confirm your own compliance position rather than taking a website's word for it.