Short answer: a browser green screen remover keys one still frame, not an MP4. To remove green from video, export numbered PNG frames and key them, or run a per-frame chroma key in FFmpeg, then encode VP9 WebM with alpha or ProRes 4444. A transparent H.264 MP4 does not exist. The keyer on this site is the still-frame step; the commands below are the video step.
Pick the output before you key anything
Most dead ends in video keying are container problems, not keying problems. The green comes off cleanly and then the file is saved into a format that cannot store a transparent pixel. Choose the deliverable first:
| Output | Alpha? | Plays or opens in | Use it when |
|---|---|---|---|
WebM, VP9yuva420p | Yes, in a side channel | Chrome, Firefox, Edge; test Safari before delivery | Web overlay, browser demo, lightweight delivery |
MOV, ProRes 4444yuva444p10le | Yes | Premiere, Resolve, Final Cut, After Effects | You are handing the clip to an editor or colourist |
PNG sequencergba | Yes, per file | Every compositor and the keyer on this site | You want to inspect or fix individual frames |
| MP4, H.264 | No | Everything | Only a final composite with an opaque background |
| MP4, HEVC with alpha | Apple-only variant | Apple platforms | Not a portable deliverable; do not promise it |
| GIF | 1-bit only | Browsers, chat apps | Hard-edged stickers; no soft hair or motion blur |
The word “transparent MP4” is the usual trap: MP4 is a container and can hold several codecs, but the H.264 stream inside a normal MP4 has no alpha plane to fill. Re-encoding it as WebM does not add one either — the alpha has to be created by the key, then carried by a codec that supports it.
The path from MP4 to a keyed clip
1. Optional: export a frame sequence
Do this when you want to inspect or hand-fix frames, or when you want to test the key on one still before committing the whole clip. -fps_mode passthrough keeps the source frame count instead of dropping or duplicating frames to fit a constant rate.
ffmpeg -i input.mp4 -fps_mode passthrough frames/%05d.png
Verified on a 2-second, 30 fps, 1280×720 test clip: 60 PNGs out, numbered 00001–00060.
2. Key every frame
For a delivery clip, let FFmpeg key the sequence in one pass. This writes RGBA PNGs, so the transparency survives the still-image step:
ffmpeg -i input.mp4 -vf "chromakey=0x00b140:0.10:0.06,format=rgba" -pix_fmt rgba keyed/%05d.png
For a handful of frames, you can key them one at a time in the browser keyer and download transparent PNGs. That is practical for a thumbnail or a five-frame test, not for 900 frames.
3. Encode the keyed frames with alpha
WebM for the browser. -auto-alt-ref 0 matters: alternative reference frames and the VP9 alpha side channel do not mix reliably.
ffmpeg -framerate 30 -i keyed/%05d.png -c:v libvpx-vp9 -pix_fmt yuva420p -b:v 0 -crf 28 -auto-alt-ref 0 out.webm
ProRes 4444 for an editor:
ffmpeg -i input.mp4 -vf "chromakey=0x00b140:0.10:0.06,format=yuva444p10le" -c:v prores_ks -profile:v 4444 -pix_fmt yuva444p10le out.mov
Set -framerate to the real source rate. A 29.97 fps clip needs 30000/1001, not 30, or the audio and duration drift.
4. One-pass version, if you do not need the frames
The same key, straight from the MP4 to WebM, without the intermediate PNGs:
ffmpeg -i input.mp4 -vf "chromakey=0x00b140:0.10:0.06,format=yuva420p" -c:v libvpx-vp9 -pix_fmt yuva420p -b:v 0 -crf 28 -auto-alt-ref 0 out.webm
This is the fastest path and the one to use once the key values are settled. It gives up the ability to fix a single bad frame, which is exactly what the sequence path buys you.
The frame budget, measured
A 10-second clip is not one key operation; it is 240 to 600 of them. To make that concrete, the exact colour-distance loop used by this site's browser keyer was run over synthetic frames in Node 24 on this machine. The table is the pure pixel loop only — no PNG decoding, no encoding, no disk I/O.
| Frame size | Median per frame | 240 frames (10 s at 24 fps) | 300 frames (10 s at 30 fps) | 900 frames (30 s at 30 fps) |
|---|---|---|---|---|
| 1280 × 720 | 18.2 ms | 4.4 s | 5.4 s | 16.3 s |
| 1920 × 1080 | 82.5 ms | 19.8 s | 24.8 s | 74.3 s |
| 3840 × 2160 | 441.4 ms | 1 min 46 s | 2 min 12 s | 6 min 37 s |
Measured 2026-10-21, median of 15 runs per size, AMD EPYC 9754, Node v24.19.0. This is the keying maths alone; a real encode is slower. Use it to see the shape of the cost: in this run 4K took about 24× the per-frame time of 720p, while it has only 9× the pixels.
Storage is the other number people underestimate. A raw RGBA frame at 1920×1080 is 8.29 MB, so 300 of them are 2.32 GiB before any compression. PNG shrinks a flat green background dramatically, so do not budget from the raw figure — but do not expect a 900-frame 4K sequence to fit in a small temp folder either.
Measured: a still keyer's tolerance is not FFmpeg's similarity
Both controls are often labelled as a percentage, and they are not the same measurement. This site's keyer compares RGB distance from the sampled colour, divided by the maximum possible RGB distance (441.67). FFmpeg's chromakey compares chroma in YUV after chroma subsampling. Copying 14% from one box into the other is a guess, not a conversion.
To show the size of the gap, a 2-second 1280×720 test clip was built with a flat #00b140 background, a skin-coloured block (#d9a07a), a white block (#e6ece6) and a green shirt block (#2f7d3f). It was encoded to VP9 at five similarity values with blend fixed at 0.06, then decoded and sampled. Alpha 0 means fully transparent; 255 means fully opaque.
| FFmpeg similarity | Background | Skin | White | Green shirt |
|---|---|---|---|---|
| 0.06 | 0 | 255 | 255 | 255 |
| 0.08 | 0 | 255 | 255 | 251 |
| 0.10 | 0 | 255 | 255 | 166 |
| 0.12 | 0 | 255 | 255 | 81 |
| 0.14 | 0 | 255 | 255 | 0 |
Measured 2026-10-21 with FFmpeg 9.0.2, VP9 CRF 24, decoded with -c:v libvpx-vp9. Synthetic test clip, so treat the values as a scale check, not a preset for real footage.
The useful result is not any single row. It is that the background was already gone at 0.06, while the green shirt only died at 0.14 — and at 0.14, the still keyer's RGB maths would still place that shirt outside a 14% tolerance (it sits 15.9% from the key colour). If you tune in one tool and paste the number into the other, you can delete a costume without ever seeing the background change. Tune FFmpeg from 0.06 upward on your own clip, and judge the edge on a frame, not on the slider.
Check the alpha before you call it done
- Do not trust
pix_fmt. A VP9 WebM with working alpha can still be reported asyuv420p. Check for the tag instead:ffprobe -show_streams out.webmshould printTAG:alpha_mode=1. - Decode the alpha, not just the picture. In this test, FFmpeg's native VP9 decoder would not expose the alpha plane;
-c:v libvpx-vp9did. Read one frame as RGBA and confirm a background pixel is 0 and a subject pixel is 255. - Composite it over white or red, not black. Black hides a black matte and makes a failed alpha look intentional. A bright background shows a grey or green fringe immediately.
- Check three frames at least: the first, the last, and one with fast motion. Motion blur is where the key and the encoder disagree most.
- Play it in the player you will deliver to. A file can be correct and still fail in a player that ignores WebM alpha. Test the actual target, not only the editor.
- Confirm duration and frame count. A sequence rebuilt at the wrong
-framerateis the quietest failure here: the transparency is perfect and the clip is the wrong length.
Green screen remover for video: questions
Can you remove a green screen from a video, or only from photos?
Both, but not with the same tool. The keyer on this site removes green from a still image and exports a PNG. A video needs the key to run on every frame — either as a chroma-key effect in an editor or as FFmpeg's chromakey filter, which is what the commands above use. The browser keyer is still useful for testing one frame before committing a long job.
Why is my keyed WebM background always black?
Usually because the filter graph puts the keyed clip on top of a black background before encoding. A real question on Video Stack Exchange describes exactly this: the chroma key runs, the output is WebM, and the background is black rather than transparent. If you overlay the keyed stream onto a black colour source, the result has no alpha left to carry — it is a picture of a key on black. Encode the keyed stream directly with format=yuva420p, -pix_fmt yuva420p and -auto-alt-ref 0, and do not add an opaque layer unless you want one. Source: video.stackexchange.com question 36063.
Can I get a PNG sequence with the green already transparent?
Yes. Add ,format=rgba after the key and write PNGs with -pix_fmt rgba. In a test here, a 2-second 30 fps clip produced 60 RGBA PNGs, each with alpha 0 on the background and 255 on the subject. That sequence is what you hand to a compositor, or rebuild into WebM with the -framerate command above.
Why can't I export a transparent MP4?
Because the common codec inside an MP4, H.264, has no alpha channel. It stores brightness and colour, not per-pixel transparency. Re-muxing to MP4 cannot add the missing plane. If a converter offers a “transparent MP4”, check what it actually wrote: a composite on a solid colour, a WebM with the wrong extension, or a proprietary variant that only one app can open. Use WebM/VP9 for the browser, ProRes 4444 for editing, or a PNG sequence for compositing.
Can I key a green and a blue screen in the same video?
Yes, but not by putting two chromakey filters in a row. Tested here on a six-block strip: the second filter overwrote the first matte, and the green block ended at alpha 223 — the blue-only result. Build one matte per colour, combine them with blend=all_mode=darken, then attach the darker matte with alphamerge. The full command, the decoded alpha values, and the 0.27-point tolerance window that decides whether blue clothing survives are on green screen remover for two colors.
Is 8-bit 4:2:0 footage good enough for a green screen key?
Usually yes, if you key at the resolution you shot. 4:2:0 stores colour at half width and half height, so a 3840×2160 clip has a 1920×1080 chroma plane and a 1920×1080 clip has a 960×540 one. The key reads chroma, so the matte is effectively built at that smaller size and then stretched over the full frame — which is why a 4K 4:2:0 source keys more cleanly than a 1080p 4:2:0 source. 8-bit is the smaller problem: a lit green screen occupies a narrow range, so banding matters less than compression noise. One common misconception is that downscaling 4K 4:2:0 to 1080p turns it into 4:2:2. It does not: you still have one chroma sample per 2×2 luma block, and averaging can lower noise but cannot restore samples that were never recorded. The practical order is shoot 4K, key 4K, then downscale the keyed result — not downscale first. The same question was asked on Video Stack Exchange in question 32485.
Next step
If you only need one frame, key it in the browser and use the result to choose your FFmpeg values. If you are building the background rather than removing one, start at the Seedance 2.5 job builder or read the guides.