How to extract frames from a video

You do not need to install anything

Every browser has had a hardware video decoder in it for a decade. Set the playback position, wait for the seek to complete, and draw the video element onto a canvas, that is the entire technique, and it is why a frame extractor does not need a server, an upload, or a size limit.

It also means the file never leaves your machine, which matters more than it sounds for footage you would rather not hand to a website.

One frame, or a run of them

These are different jobs and it is worth knowing which you are doing.

One frame means you have a moment in mind: the instant the ball crosses the line, the slide before the cut. You want to step to it precisely, which means stepping at the video's real frame rate rather than nudging a scrub bar.

A run of frames means you want coverage: a contact sheet, a set of reference stills, every second of a two-minute clip. You want an interval and a range, and you want them back as one archive rather than three hundred separate downloads.

Frame rate is the thing to get right

If you are stepping frame by frame, the step size has to match the video or every step lands between frames and the picture barely changes.

The complication is that a web page cannot read the frame rate from the file. Containers carry a nominal rate that is not exposed, and variable-frame-rate video (which is what most screen recordings and phone videos are) does not have a single one at all.

What can be done is to measure it: ask the browser how many frames it has actually presented and at what media time, take two readings, and divide. That gives the real interval between real frames.

One trap in that measurement. The common rates cluster:

29.97 and 30 are a tenth of a percent apart. Any tolerance wide enough to absorb measurement noise will match both, so a naive implementation picks whichever it checks first, and reading a genuine 30fps clip as 29.97 produces a step that drifts off the frame boundary within a few hundred frames. The answer has to be the nearest standard rate, not the first plausible one.

If a tool lets you override the detected rate, that is not a sign it is guessing badly. It is a sign it knows it might be.

Choosing a format

• PNG is lossless. Use it if the frame is going into an editor, or if it

is mostly text (a slide, a screen recording, a diagram) where JPEG's ringing around sharp edges is obvious.

• JPG at 90-ish is right for photographic footage and produces files

around a tenth the size.

• WebP is smaller again at similar quality and is fine for anything

destined for a web page.

A caution worth knowing: video is already heavily compressed, so a frame you pull out carries the codec's artefacts. Saving it as PNG preserves those artefacts perfectly. It does not recover anything.

Naming, so the files sort

This sounds trivial until you have three hundred files in a folder. A name carrying a bare number of seconds sorts wrongly the moment the clip passes ten seconds: frame-9 lands after frame-10.

The naming that works is fixed-width and time-based:

`` holiday-00h00m12s500ms.jpg ``

Fixed width means a file browser sorting by name sorts by time. Milliseconds rather than hundredths means two adjacent frames at 60fps, 16ms apart, cannot collide, and two files with the same name is the one outcome a batch extractor must never produce.

Why there is a cap

Our extractor stops at 300 frames a run. That is not a licence limit; it is what a browser holds comfortably. Asking for 30fps across a two-hour film is 216,000 images, and what you actually wanted was a sample.

When the cap bites, the honest thing is to say so: "that asks for 18,001 frames; taking the first 300", rather than silently returning a fraction of what was requested. A longer interval or a shorter range covers more of the video.

Formats that will not open

MP4, WebM, MOV and M4V are safe bets. MKV and AVI often will not decode, because the browser's decoder does not handle every container even when it handles the codec inside.

That is the browser's limit rather than the tool's, and there is no way around it from a web page. It is better said plainly than hidden behind a spinner that never stops.