Why You Don't Need ffmpeg to Pull a Still Out of a Video

Grabbing a still image out of a video file - a thumbnail, a specific moment to reference, a contact sheet of frames - has traditionally meant one of two things: installing ffmpeg and using its command line (genuinely capable, genuinely not something most people want to set up for an occasional task), or uploading the video to a web tool that processes it on a server and hands back the frames, trading your file's privacy and a real upload wait for convenience. Neither is actually required for the common case of a browser-playable video file, because a browser can already decode video and capture a frame from it natively, with nothing extra installed.

What a browser already does, that most tools don't use

Every current browser ships a full, hardware-accelerated video decoder as a basic part of playing back a <video> element - the same decoder that runs when you watch any video on any website. That decoder can be told to seek to a specific timestamp and, once it's there, the currently-decoded frame can be captured directly as an image using a standard browser API (createImageBitmap()), with no video-processing library involved at all. The browser is already doing the hard part - decoding the video's actual codec, whatever it is - as a normal, everyday part of video playback; capturing a still from that decoded frame is a comparatively small additional step.

What actually happens versus what you might expect

What this means in practice

Because there's no large processing library to download before the tool can run, and no server round trip to wait on, the whole operation starts working the moment a video file is chosen - there's no "loading the engine" delay some heavier browser-based media tools carry while a multi-megabyte WASM binary downloads and initializes. The heaviest actual work - encoding each captured frame to a JPG or PNG, and building the final zip file - happens in a background worker, off the page's main thread, so the tab stays responsive while a longer extraction runs.

Where the actual work happens once a frame is captured

Capturing a frame is only half the job - it also has to be encoded into an actual JPG or PNG file, and if you're extracting many frames, all of them need bundling into a single downloadable zip. Both of those steps run inside a background worker, a separate thread from the page you're looking at, using the browser's own OffscreenCanvas encoding API and an already-vendored zip library. This is worth naming because it's the part of the job that actually takes real, sustained CPU time on a longer extraction - and keeping it off the main thread is what keeps the page itself responsive (scrollable, clickable, not frozen) while a bigger extraction runs in the background.

The honest limit of this approach

This works for exactly what it's built for: a video file your browser can already play natively (MP4, WebM, MOV, or Ogg, in a codec your browser supports). It's not a substitute for a full video-processing toolkit for every conceivable format or an exotic professional codec a browser's built-in decoder doesn't recognize - that's genuinely a different, harder problem this approach doesn't try to solve. For the overwhelming majority of real video files people actually have sitting on a phone or a laptop, though, the browser's own decoder already covers it.

Why this matters for privacy specifically

Because there's no server involved at any step and no external library being fetched in, this tool makes no network request of any kind once the page has loaded - not even the narrower "nothing is uploaded, but a model or library is fetched from elsewhere" caveat some other browser-based tools carry honestly on their own pages. The video is read, decoded, sampled, and zipped up entirely on your device, with nothing else touching a network at any point.

Why "no upload" is a stronger claim here than on most tools

Several tools on this site process a file entirely in the browser but still fetch some kind of supporting asset from a network the first time you use them - a WASM module, a machine-learning model - which is disclosed plainly where it applies, since it's a real, if narrow, exception to "nothing leaves your browser." This tool has no such exception: because it uses the browser's own built-in decoder rather than any fetched-in library, there is genuinely nothing to download beyond the tool's own small JavaScript files, and no network request of any kind happens once the page itself has loaded. It's one of the few tools on this site where the privacy claim needs no footnote at all.

For the actual step-by-step of pulling frames out at a chosen rate, see how to make a contact sheet from a video. And for the specific case of sampling frames for a dataset rather than a visual contact sheet, see extracting training images from a video.