Granting a website access to your camera feels like a big trust decision, and it is — but the underlying mechanics are more transparent than most people realise. Browsers expose the camera through a tightly controlled API, and you can verify exactly what a page is doing with it in about ninety seconds using tools that ship with every modern browser. This guide walks through how the system works, what to look for, and how to reason about the difference between "local-only photos" and "local-only everything".
The browser owns the camera, not the page
When you open a site that uses the camera, the page does not get the camera directly. It calls a browser API — navigator.mediaDevices.getUserMedia() — and the browser decides whether to grant access. The browser shows the permission prompt, manages the device, chooses which camera to expose, and can revoke access at any time.
Every modern browser also shows a persistent indicator while the camera is in use: a red dot in the tab title, a camera icon in the address bar, or both. On iOS Safari a green dot appears in the status bar. On macOS the green LED next to the camera lens is wired directly to the sensor's power line — it is physically impossible for software to turn on the camera without turning on the LED. If none of these indicators are on, no page is using your camera at that moment, regardless of what the page claims.
Permissions are scoped to the origin
Camera permission is granted per origin (the combination of scheme, domain and port), not per page. Granting access to flashframe.app does not grant access to any other site, and does not persist if you visit the same tool at a different domain. The permission itself persists across visits unless you revoke it.
You can revoke access at any time from the site permissions menu in the address bar (the padlock or "tune" icon). Revoking immediately stops the live feed; the page cannot resume without prompting you again. On mobile, the same control lives inside the browser's site settings menu — Chrome, Safari and Firefox all expose it within one or two taps.
What "processed locally" actually means
Once the page has access to the camera stream, the video frames live in your browser's memory. The page can do three things with them:
- Display them on screen.
- Read individual frames as image data for filtering, cropping or capture.
- Send them over the network to a server.
The first two are local: the data never leaves your device. The third is what most people worry about. There is no in-between — either the page initiates a network request to upload the data, or it does not. The browser does not silently forward video frames anywhere; every byte that leaves the page is initiated by code you can inspect.
How to verify nothing is being uploaded
Every browser has a built-in network inspector. Open developer tools (Cmd/Ctrl + Shift + I in Chrome, Edge or Firefox; Cmd + Option + I in Safari with developer tools enabled) and switch to the Network tab. Filter by "Img" or "Fetch/XHR" and watch what happens when you take a photo.
If a site processes photos locally, you will see no outgoing request after you press the shutter. The only requests you will see are static assets the page itself loads (JavaScript, CSS, fonts, images). If the site is uploading your photos, you will see a POST request carrying image data — usually a few hundred kilobytes to a few megabytes per shot. You do not need to be a developer to spot this; the request size and the timing (right after you click the shutter) are unmistakable.
A more paranoid variant: open the Network tab, clear it, take ten photos in a row, and watch. Ten photos on a local-only site produce zero new requests. Ten photos on a cloud-processing site produce ten large uploads and, usually, ten equally large downloads of the processed result.
Why FLASHFRAME is local-only
FLASHFRAME's filters, photobooth, Polaroid maker, Instax maker, collage tool and exports all run in your browser. The camera feed, every filtered frame, and every exported JPG, PNG or GIF stay in your tab's memory until you save them. Nothing is uploaded. If you close the tab without saving, the photo is gone — there is no draft on a server to recover from.
That is a design choice with real trade-offs. There is no cloud gallery and no cross-device sync — a strip you shoot on your laptop will not show up on your phone unless you export and share it yourself. The benefit is that there is no server to compromise, no account to leak, and no AI training pipeline for you to opt out of. Your face never touches infrastructure you do not control.
Things to watch for on any camera site
- HTTPS only. Browsers refuse to grant camera permission to non-HTTPS sites, with the narrow exception of
localhost. If a site asks for camera access over plain HTTP, do not grant it — the request itself is a red flag. - The recording indicator. The red dot or camera icon should be visible the whole time the page is using the camera, and should turn off as soon as you stop the stream. If the indicator stays on after you expect the camera to be off, refresh the tab.
- No silent uploads. If the page lets you take a photo and you immediately see network activity in the inspector, something is being sent somewhere. A local-only site produces silence on the network at shutter time.
- Clear privacy policy. The policy should plainly say whether photos are uploaded, where they go, who can access them, and how long they are kept. Vague references to "our partners" are not the same as an unambiguous "we do not upload your photos".
- No account required for the camera itself. If a site demands you sign in before it will show you your own webcam, ask why — a local-only tool has no technical reason to know who you are.
Cookies, storage and analytics are separate
"Local-only photos" does not automatically mean "local-only everything". Many local-first camera tools still use cookies for advertising, store small preferences in localStorage, or run analytics on which pages you visit. Those are normal web behaviours and are governed by the site's privacy policy, not by the camera API.
On FLASHFRAME, localStorage stores things like your last selected filter and shoot drafts — none of which contain photo data — and the only third-party requests are for ads on editorial pages, after consent where required by law. The camera routes themselves load no ads and no analytics.
Mobile browsers and permission memory
iOS Safari resets camera permission every time you leave the tab and come back, which is strict but occasionally annoying. Chrome on Android remembers the choice per site. Firefox on both platforms asks you every session by default and offers a "remember" checkbox. None of these behaviours change what a page can do with the camera; they only change how often you have to reconfirm. If a photobooth site works differently across your devices, the browser is the reason, not the site.
FAQ
Can a website turn on my camera without asking? No. Modern browsers require an explicit user gesture (a click or tap) and an explicit permission grant beforegetUserMedia() will return a stream. There is no supported API path around this.
What about photos I already saved? A web page can only read files you drag in or select through a file picker. It cannot read your camera roll, downloads folder or arbitrary files on your device.
Do local-only sites still work offline? Sometimes. Pure client-side tools that have already loaded their JavaScript can keep running without the network, but if the page reloads it needs a connection to fetch the code again. Progressive web app installations extend this by caching everything.
Is a browser photobooth safer than a native camera app? Different, not necessarily safer. A native app has more sensor access but goes through the OS permission system. A browser tool is sandboxed from your files and other apps, which is a meaningful boundary for casual use.
Further reading
- Better photobooth photos — practical setup tips
- Exporting photos for Stories without losing quality
- FLASHFRAME's privacy policy
Bottom line
The browser gives you the tools to know exactly what a camera site is doing with your video. Use the recording indicator, the permission menu and the network inspector, and you do not have to take any site's word for it — including ours.