Your footage never leaves your device. Verify it yourself.

Every recorder says something like this. The difference with a local-first web app is that you don't have to believe us — the browser's own developer tools show every byte that leaves the page. This walkthrough takes about five minutes and requires no technical background beyond following along. If you ever see this app upload your media, that's a critical bug and a broken promise; we're staking the product on you not finding one.

The walkthrough

1. Open DevTools. In Chrome or Edge, press F12 (or Cmd+Option+I on a Mac) and select the Network tab. Check Preserve log so nothing disappears between page loads.
2. Open the app at screencastkit.app/app. You'll see a burst of requests: HTML, JavaScript, CSS, fonts, wallpaper images. All static assets, all from our own origin. This is the app downloading itself — the last time the network matters.
3. Record something. Start a recording, capture a tab or your screen for a minute, stop. Watch the Network panel while you do: no requests appear. Your frames are being written to your browser's private storage on your disk, not to a socket.
4. Edit and export. Add zooms, change the wallpaper, then export an MP4. Still nothing. A one-minute 1080p video is tens of megabytes — if it were being uploaded, you'd see a massive POST request sitting in the panel and your upload LED blinking. There is no such request, because there is no server that accepts media. The MP4 lands in your downloads straight from the browser's encoder.
5. Sort by size, just to be thorough. Click the Size column. Everything you see is kilobyte-scale assets flowing to you. Media-payload traffic flowing from you: zero bytes.

The complete list of requests we do make

"No uploads" doesn't mean "no network ever" — here is the exhaustive list of what you can see, so nothing in the panel surprises you:

That list is enforced, not just promised: the site ships a Content-Security-Policy whose connect-src allows exactly our origin, our API, and Paddle. The browser itself blocks the app from talking anywhere else — even a compromised dependency couldn't quietly exfiltrate frames to a third-party host.

What we never see

• Your screen pixels — recorded frames go from the capture API to your disk.
• Your microphone and system audio — mixed and encoded locally.
• Your webcam — composited on your GPU, never transmitted.
• Window titles, filenames, URLs of what you record — we have no channel for them.

Where your data actually lives

Recordings and projects are stored in the Origin Private File System (OPFS) — a private area inside your browser profile, on your disk, sandboxed to this site. The app's storage panel shows usage and lets you delete anything; recordings you don't keep are garbage-collected automatically after 30 days. Clearing site data in your browser wipes everything instantly, no request to us required — we couldn't retain a copy, because we never had one.

And the companion extension?

The optional extension exists for exactly one purpose: capturing pointer and click telemetry (positions and timestamps) during browser-tab recordings so the editor can generate automatic zooms. That telemetry is relayed only to the ScreenCastKit page running on this origin, on your machine — the extension has no remote backend, stores nothing outside your browser, and phones nowhere. The same DevTools test applies: run a recording with the extension active and watch the Network panel stay quiet.

The honest caveat, stated plainly: a page can't prove a negative about its future — we could theoretically ship a malicious update tomorrow. What we can do is make the claim checkable at any moment, enforce it with CSP, and build the entire business so it doesn't depend on your data. Your hardware renders, so we don't need your footage. That's not virtue; it's architecture.