Video Frame Extractor
runs in your browserTake still frames out of a video in your browser: a set number spread across it, one every few seconds, or a single moment. Saves as PNG, JPEG or WebP.
Drop a file here, or .
Drop a video — MP4, WebM, MOV, anything your browser plays
Nothing is uploaded — the file is read by your browser’s own video decoder, so whatever it can play, this can take frames from.
about this tool
Drop a video, choose how many stills you want, and save them. Everything runs in the page — the file is handed to the same decoder your browser uses to play it, and nothing is uploaded.
The time you ask for is not the time you get
A video has no picture at five seconds. It has a sequence of frames, each with a presentation time the encoder chose, and asking for five seconds gets you whichever one was on screen at that moment. At 25fps that frame might have started at 4.960s; at 24fps in a film it might be 4.958s.
Most extractors print the time you asked for on the frame they hand back,
which is a small untruth repeated once per still. Where your browser supports
requestVideoFrameCallback,
the real presentation timestamp of the frame that was painted is read back and
used — under the thumbnail, and in the filename.
A frame further from the asked-for moment than one frame interval is called out. The interval is not guessed: HTML exposes no frame rate, so it is measured from the gaps between the timestamps already collected. That matters, because a fixed threshold cannot work — one frame is 40ms at 25fps but 17ms at 60fps, so any constant is either deaf on fast footage or deafening on slow.
Where the browser reports no frame time at all — Firefox before 132, Safari before 15.4 — the time shown is the one you asked for, and it is labelled as such rather than presented as measured.
This matters as soon as you are comparing two files, or matching a still to a subtitle cue, or checking whether an event happens before or after another.
How the frames are chosen
A number of frames spreads them evenly and samples the middle of each equal slice. So four frames across an eight-second clip are taken at 1s, 3s, 5s and 7s rather than 0s, 2.67s, 5.33s and 8s. Two reasons: most videos open on black or a fade, so a frame at zero is usually wasted, and the final instant is not a valid position at all — see below.
One every N seconds starts at zero, because that is what an interval means, and steps until the end.
One frame takes the moment you name — written as 00:00:05.250, or
1:30, or just a number of seconds. Name a time past the end and you get the
last frame, with a line saying that is what happened rather than letting you
believe the video was longer than it is.
Why nothing is ever taken from the very end
Seeking to exactly the duration lands past the last frame's presentation time, and browsers do not agree about what happens there — some clamp back to the final frame, some fire the seek event without painting anything, some simply stall. So every plan stops a millisecond short. It is the sort of thing that works on your machine and produces a blank image or a hung tab on somebody else's.
What it can open
Whatever your browser can play, and nothing else, because it is the same decoder. In practice:
| Works | Usually does not | |---|---| | MP4 with H.264, anywhere | MKV, whatever is inside it | | WebM with VP8 or VP9 (Safari 16+) | AV1 inside WebM, in Safari | | MOV with H.264 | ProRes, DNxHD and other mastering codecs |
H.265 is better supported than its reputation: Chrome 107, Edge, Firefox 137 and Safari all decode it where the hardware can. MKV is the reliable failure — browsers ship a demuxer for a web-safe subset of Matroska rather than for the format, so what is inside the file is beside the point.
If it plays in a browser tab, frames can be taken from it. If it does not, the tool says so rather than producing something blank.
Size, format and the limit
PNG is exact — the pixels are the decoded frame, which is what you want for anything you will edit or compare. JPEG is roughly a tenth of the size and right for a contact sheet. WebP is smaller than both at the same quality. The quality setting only applies to the two lossy ones and disappears for PNG, because it would do nothing.
Frames can be scaled down on the way out, never up. Scaling up would invent detail that is not in the source.
Two hundred frames is the ceiling. Each one is a full-resolution bitmap held in memory until you save it, so two hundred stills from a 4K file is already several gigabytes — and packing a zip needs several times that at once, which is why there is a ceiling on that too, and why it refuses rather than taking the tab down with it.
What happens at the ceiling depends on which way you asked. A number of frames
is re-spread: ask for five hundred and you get two hundred, still covering the
whole video. An interval is not, because the interval is the thing you asked
for: you get the first two hundred, which may only reach the first minute, and
the tool says how far it got so you can widen the gap. For every frame of a
long video, ffmpeg is the right tool — it streams them to disk instead of
holding them all at once.
WebP appears only if your browser can write it. A canvas asked for a format it
does not support quietly returns PNG, so offering it everywhere would hand
some people PNG bytes in a file named .webp, at PNG file sizes, under a
heading claiming WebP is the smallest of the three.
One caveat worth knowing: frames are drawn through a canvas, and browsers differ in how they handle a video's colour space on the way. An ordinary SDR file comes out matching what you saw. HDR footage will look flatter, because it has been tone-mapped down to a standard-range image.
This takes stills out. If what you want back is something that moves — a GIF, or the same clip trimmed and re-encoded — that is video to GIF, trim & convert instead.
To read what is actually inside a file before pulling stills out of it — the container, the codecs, the frame rate and whether your browser can play it at all — the media inspector answers that first. Once you have the stills, the image compressor will get a contact sheet down to a sensible size.
questions
- Why is the frame not from exactly the time I asked for?
- Because a video does not have a picture at every instant — it has frames, each with a presentation time the encoder chose. Asking for five seconds gets you whichever frame was on screen at that moment, which might have started at 4.967s. Where your browser reports the real timestamp it is shown under the frame and used in the filename, so you get the time you actually have rather than the time you asked for. One frame is 40ms at 25fps but 17ms at 60fps, so the interval is measured from the frames already taken rather than assumed. Where the browser reports no frame times, the time shown is labelled as the one you asked for.
- Does my video get uploaded?
- No. The file is handed to the same video decoder your browser uses to play it, and each frame is drawn onto a canvas in the page. Nothing is sent anywhere, and there is no server here that could receive it. That also means a very large file costs you nothing in upload time — it is read from disk as it seeks.
- Why will it not open my file?
- Because this uses your browser’s decoder, so it can open whatever your browser can play and nothing else. MP4 with H.264 is the safe bet everywhere. WebM needs Safari 16 or later, and AV1 inside WebM does not play in Safari at all. MKV usually fails whatever is inside it, because browsers ship a demuxer for a web-safe subset of Matroska rather than for the format. H.265 is more widely decoded than its reputation suggests — Chrome 107, Edge, Firefox 137 and Safari all manage it where the hardware does — while ProRes and other mastering codecs are Safari-only at best. If the video plays in a browser tab, frames can be taken from it.
- Which format should I save as?
- PNG for anything you will edit or compare, because it is exact — the pixels are the decoded frame. JPEG for a contact sheet or a quick look, at maybe a tenth of the size. WebP splits the difference and is usually smaller than both. It only appears if your browser can actually write it: a canvas asked for a format it does not support returns PNG and says nothing, which would otherwise hand you PNG bytes in a file named .webp. The quality setting does nothing for PNG, which is why it disappears when you pick it.
- Can I extract every single frame?
- Not here. The limit is 200, because each frame is a full-resolution bitmap held in memory until you save it — 200 frames of 4K is already several gigabytes, and building a zip needs several times that again, so there is a ceiling on that too. Ask for more than 200 spread across the video and you get 200, still spread across the whole of it; ask for an interval that would produce more and you get the first 200, which covers only the start — and the tool says how far it reached. For every frame of a long video you want ffmpeg, which streams them to disk rather than holding them.
- Why is the first frame black?
- Most videos open on a fade-in or a black slate, so a frame taken at 00:00:00.000 is often blank. When you ask for a number of frames this takes the middle of each equal slice rather than the edges, which avoids both that and the end of the file. In interval mode the first frame is at zero, because that is what an interval means.
- Are the colours exactly what I see in the player?
- Close, but not guaranteed. The frame is drawn through a canvas, and browsers differ in how they apply the video’s colour space and any HDR transfer curve on the way. For an SDR H.264 file the result matches. For HDR footage expect the still to look flatter than the playback, because it has been tone-mapped to a standard-range image.
- Can it tell me the frame rate?
- Not reliably, and it does not claim to. HTML gives no frame rate for a video, and the only way to estimate one is to play the file and count frames as they arrive, which takes as long as the video. What is shown instead is each frame’s real presentation time, which is the thing you would work the rate out from.
- Why did it stop partway through?
- Usually a seek that never completed. Some files — particularly ones with sparse keyframes or a damaged index — leave the decoder unable to reach a position, and rather than hang, the tool gives each seek eight seconds and then gives up on that one frame. The rest of the run carries on, the count at the end says how many could not be decoded, and everything taken is kept and saveable.