How to Extract Frames from Footage You Cannot Upload

When "just use an online converter" is not an option

Most of the time, uploading a video to a web converter is completely fine. You have a clip from a public video, you want some stills, nobody cares where the processing happens.

Then there are the files where it is not fine, and the reason is rarely paranoia — it is that someone else already decided:

• Footage of a product that has not been announced yet.
• Client material covered by a contract that specifies where data may be processed.
• Recordings containing identifiable people, which in the EU and UK makes the file personal data with real obligations attached.
• Anything connected to a legal matter, where chain of custody is part of the point.
• Internal recordings — an incident replay, a pre-release demo, a customer call.

In those cases the question is not "which converter is best" but "does this file leave the machine at all".

What uploading actually involves

Worth being precise, because the risk is usually described too vaguely to act on. When you upload a video to a conversion service, at minimum:

• The complete file lands on a server you do not control. Not a frame, not a thumbnail — every byte, including whatever is in the parts of the video you never intended anyone to watch.
• It is written to disk. Processing needs a file, so it is stored, however briefly. It may be replicated for durability.
• Results usually sit behind an unauthenticated URL. Most converters give you a link rather than a login. Anyone with the link has the content, and links leak through browser history, shared screenshots, and proxy logs.
• Retention is a policy, not a mechanism. "Files deleted after one hour" describes intent. You cannot verify it, and it says nothing about backups.
• There may be subprocessors. The service may run on infrastructure from one company, store on another, and use a third for scanning. Each is a party to your file.

None of that makes upload-based tools bad. It makes them a poor fit for a specific category of file — which is exactly why it is worth knowing how to tell the two kinds of tool apart.

How to verify a tool is really local

Marketing copy is not evidence. "Processed in your browser" is a claim; here is how to check it in about a minute. This works on any tool, including this one — please do check.

The DevTools method

1. Open the tool's page in Chrome, Edge, or Firefox.
2. Press F12 (or Cmd + Option + I on macOS) and switch to the Network tab.
3. Tick Preserve log so nothing is cleared as you work.
4. Now select your video and run the extraction.
5. Sort the request list by size, largest first.

What you are looking for is simple: is there any outgoing request whose size is comparable to your video file? If you loaded a 400 MB clip and the largest upload in the list is a few kilobytes of analytics, the video did not go anywhere. If you see a multi-megabyte POST climbing while a progress bar fills, it did.

Ignore the incoming requests — scripts, stylesheets, fonts, and ad or analytics calls are downloads, and their presence says nothing about your file. Sort by size and look specifically at what is going out.

The offline method

Blunter and more convincing. Load the page, then in the DevTools Network tab set throttling to Offline — or simply turn off Wi-Fi. Then use the tool.

If extraction still works with no network at all, the processing is unambiguously happening on your machine. There is no clever way to fake that result. On this site the extractor keeps working offline once the page has loaded; the only things that break are the resources that were going to be fetched anyway.

The local workflow

Once you have confirmed the tool is local, the process is ordinary — that is rather the point.

1. Load the file. The browser reads it from disk into memory. Nothing is transferred, so there is no upload wait and no size ceiling imposed by a server — a 2 GB source starts immediately.
2. Choose interval and format. PNG when the frames feed into analysis or editing; JPG at 85–90% when you need many frames and the destination is a document or a ticket.
3. Narrow the range. If only thirty seconds of a long recording matter, set the time range first. Fewer frames means less memory pressure and a smaller ZIP to handle.
4. Review before exporting. The preview grid is genuinely useful for sensitive material: you can see which frames contain something that should not be shared before anything is written to disk.
5. Export. Individual frames, or the whole set as one ZIP, saved straight to your download folder.

The file never had a copy anywhere but your disk and your RAM, and the only record of the operation is the images you chose to keep.

Where local processing runs out of road

Being honest about the limits matters more than the pitch, because hitting one unexpectedly on a deadline is worse than knowing in advance.

• Memory. Extracted frames are held in RAM until you download them. Several hundred 4K PNGs can be several gigabytes and a tab can be killed for it. Work in time-range chunks for long sources, and prefer JPG when lossless is not required.
• Codec support is the browser's, not FFmpeg's. If the browser will not play it, the tool cannot read it. ProRes, DNxHD, some MKV variants and raw camera formats will not open. A local transcode to H.264 first is usually the answer — and that transcode is also local.
• No batch, no automation. One file at a time, by hand. For a hundred clips on a schedule you want a local FFmpeg script, not a browser tab.
• Your hardware is the ceiling. No server farm is helping. An old laptop extracting from 4K will be slower than a service with real machines behind it.
• Mobile is constrained. Phone browsers have much tighter memory limits; short clips work, long 4K sources often do not.

When an upload-based tool is the better choice

Genuinely often:

• The material is already public. If the video is on a public channel, the confidentiality argument does not apply and you should pick on features alone.
• You need GIF creation, not frame extraction. Tools like EzGIF are built around producing and optimising animated GIFs — palettes, dithering, looping, per-frame timing. That is a different job from exporting stills, and they do it well.
• You are on a phone. Server-side processing sidesteps mobile memory limits entirely.
• The input is a URL, not a file. Fetching from a link is something a server can do and a local page cannot.
• You want a link to share. Server-side results come with a URL; local results come with a file you then have to send.

The distinction is not privacy-conscious versus careless. It is whether the file has a constraint attached to it — and if it does, that constraint decides the tool before any feature comparison starts.

Quick reference

If you take one thing from this: run the offline test before trusting any tool with material that matters. It takes thirty seconds and it replaces a promise with a fact.