“Your files never leave your device” is now standard copy on tool sites, including this one. It is also unfalsifiable as written, which is a bad property for a privacy claim.
The good news is that it is falsifiable in practice. A browser cannot send a 200 MB file anywhere without making a network request, and your browser will show you every network request it makes. You do not have to take anybody’s word for this — including mine. Here is how to check, in about ninety seconds, for any tool you are considering.
The quick version
- Open the tool’s page.
- Press F12 (or right-click → Inspect) and go to the Network tab.
- Tick Preserve log so nothing is cleared by a navigation.
- Load your video into the tool and run whatever operation it offers.
- Sort the request list by size, and look at the largest thing that went out.
If the tool uploaded your file, there is a request whose payload is about the size of your video. There is no way to hide it: the bytes have to cross the wire, and the wire is instrumented.
Reading the Network tab properly
A few details make the check much more reliable.
Sort by size, and know which column you are reading. The Size column in Chrome DevTools shows the response size by default. An upload is in the request, not the response. Click a suspicious request and read Payload / Request Payload, or add the Content-Length header to what you are looking at. Firefox’s Network panel has a dedicated Request tab per entry.
Filter by request type. In Chrome, the Fetch/XHR filter narrows things to the requests a page makes programmatically. Uploads are almost always POST or PUT here, or occasionally a WebSocket. You can also filter by method by typing method:POST into the filter box.
Do not be alarmed by large downloads. A client-side tool needs a codec engine, and those are big — this site fetches about 32 MB of FFmpeg compiled to WebAssembly the first time you apply an edit. That is a download: code coming to you, not data leaving you. Check the direction before drawing a conclusion.
Watch for sendBeacon and ping. These show up in the Network panel with a type of ping or beacon. They are how analytics fires and, in principle, how something could exfiltrate small amounts of data. They are small by design and cannot carry a video, but it is worth seeing what a site sends and how often.
Check WebSockets separately. In Chrome the WS filter lists websocket connections, and clicking one shows every frame sent and received. A tool streaming your file to a server over a socket would be visible here.
The offline test — the one that actually settles it
The Network tab tells you what happened. The offline test tells you what is possible, and it is the more convincing of the two.
- Load the page normally and run one small edit, so the engine gets cached.
- In DevTools, open the Network tab and set the throttling dropdown to Offline. (Or just turn off Wi-Fi.)
- Reload the page and edit a video again.
If the tool still works with the network switched off, the processing cannot be happening on a server. There is no server to reach. This is a much stronger signal than a clean network log, because it rules out the possibility rather than merely observing its absence in one run.
Not every legitimate client-side tool will survive a full reload while offline — that depends on caching, not on where the processing happens. If the reload fails but editing an already-loaded page works offline, you have still learned the important thing.
Other things worth looking at
The <input type="file"> is not evidence of anything. A file input is how a page gets any access to a local file, including for purely local processing. Its presence tells you nothing.
Timing is a tell. A server-based tool has to upload your file before it can start. On a large file over a domestic connection that takes minutes, and the progress bar will say so. A tool that begins processing a 500 MB file the instant you drop it in did not upload it first — physics will not allow it.
Check the third parties too. “We do not upload your video” can be entirely true while the page still loads a dozen trackers, an ad network and a session recorder. Look at the hosts in the Network tab, not just the sizes. A session-replay script cannot see your video, but it can see everything else you do on the page.
Look at what happens after you leave. With Preserve log on, navigate away and come back. Some tools fire their most interesting requests on unload.
What this site does, so you can check the claim against the answer
It would be poor form to write this and not state the answer for alter.video itself, so that you can go and verify it.
What is downloaded: the HTML, CSS and JavaScript for the page; the FFmpeg WebAssembly core (about 32 MB) the first time you apply an edit, cached afterwards; and nothing else. There are no webfonts and no third-party scripts other than the analytics one below.
What is uploaded: nothing containing your file. There is no upload endpoint in the application. Your video is read from disk into the tab with the File API, written into FFmpeg’s in-memory filesystem, processed there, and read back out as a Blob that the download button points at.
What else is sent: an analytics request per page view, to api.panalytics.money, plus a ping when you leave the page. It is cookie-less and records the page address, the referrer, any campaign parameters in the URL, and how long the page stayed open; your browser and a country are derived from the request itself, as they are for any web request. It has no visibility into the editor, the file you loaded, or anything you did with it. That is the complete list, and it is stated in the same terms on the privacy page.
If you run the checks above and find something that contradicts this, that is a bug worth reporting.
The limits of this method
Two honest caveats.
You are verifying one version at one moment. A site can change tomorrow. What DevTools proves is what the code you just ran did, not what the operator promises forever. For a tool you use often, it is worth re-checking occasionally — the offline test takes ten seconds.
“Not uploaded” is not the same as “no risk”. A page still runs code from a server on your machine. The meaningful guarantee of a client-side tool is narrow and specific: your file does not get copied to storage you do not control, and there is no third-party retention policy to read. That is a real and substantial guarantee. It is not a claim that the software is perfect.
More on the architecture that makes the guarantee possible: how browser video editing works, and what a private video editor actually means.