Which video format actually keeps transparency after keying?
Three of them do: MOV as QuickTime Animation, MKV as FFV1, and APNG. MP4 and GIF have no alpha channel at all and will flatten your cut-out onto a background, and WebM is deliberately not offered because VP9's alpha plane does not survive the encode — the file decodes back opaque. Reach for MOV when the clip is going into a desktop editor, APNG when it has to play in a browser or a deck, and MKV only when the maths has to be lossless and you can carry the size.
Three of the seven carry an alpha channel
The export menu lists seven options, and the split between them is not a matter of taste — it is what the container and the codec can physically store. Here is what each one actually runs.
MOV is encoded as -c:v qtrle -pix_fmt argb: QuickTime Animation, run-length encoded, 8-bit ARGB. Lossless, full colour resolution on every pixel, and the one every desktop compositor opens without being asked.
MKV is encoded as -c:v ffv1 -pix_fmt yuva420p -level 3 -g 1: FFV1, mathematically lossless, with -g 1 forcing every frame to be its own keyframe so nothing depends on a neighbouring frame surviving.
APNG is encoded as -c:v apng -plays 0. An APNG is a PNG with animation chunks bolted on: each frame is a PNG, lossless, full RGBA, and -plays 0 loops it forever. There is no codec to negotiate and no plugin to install — a browser just plays it.
MP4 is libx264 in yuv420p and GIF goes through palettegen and paletteuse. Both are flagged as no-alpha, and both will stop the export rather than hand you a file with a background baked into it.
The alpha was verified, not assumed
Every option marked as alpha-capable here was checked the same way: encode a frame that is half opaque and half fully transparent, close the file, decode it back, and read the alpha of the transparent half. It has to come back as zero. The flag was never taken from documentation, because documentation claims alpha support for combinations that do not deliver it.
That test is what removed WebM from the menu. ffmpeg accepts -pix_fmt yuva420p for VP9 and reports the output stream as yuva420p, exactly what a transparent WebM should look like on paper. The alpha plane never reaches the file. Measured on the encoder this tool bundles — ffmpeg 5.1.4, as shipped in ffmpeg.wasm 0.12.10 — and again on a desktop ffmpeg 9.0.1, both write a file that decodes back as plain yuv420p. A transparent WebM would be a file that lies about itself, so the option is not offered.
You can run the same check on any tool that advertises transparent video. One frame, about a minute, and it separates "the menu says alpha" from "the file has alpha".
The three are not interchangeable, and the edge is why
They differ in pixel format, which decides what happens to the pixels on the boundary between subject and background.
MOV stores argb: full-resolution red, green, blue and alpha for every pixel. Whatever the keyer produced at the edge, down to the partial alpha and the de-saturated fringe pixels, is stored exactly.
MKV stores yuva420p: luma and alpha at full resolution, but the two colour planes at half width and half height. The alpha survives perfectly; the colour does not. Every 2×2 block shares one chroma pair, so colour detail along a soft edge is quartered. On fine hair or a wispy edge that is the wrong place to economise, even though "lossless" reads like the safer word.
APNG stores full RGBA per frame like MOV does, but as a sequence of PNGs rather than a video stream. There is no inter-frame prediction, so nothing degrades as the clip goes on, and nothing needs a codec — which is why it plays in a browser tab, a slide deck or a chat window without anyone installing anything.
What the transparency costs, in the tool's own arithmetic
The alpha formats are lossless, so the bitrate rules that govern MP4 simply do not apply. Size is frames × width × height × bytes per pixel, using the per-pixel figures this build measured on a flat-subject test clip: 2.2 for MOV, 3.0 for MKV, 1.6 for APNG, against 0.4 for MP4 and GIF. The same formula runs inside the tool before every render.
At 1080p and 30 fps, one second of finished clip costs roughly 130 MiB as MOV, 178 MiB as MKV and 95 MiB as APNG. At 720p the same second costs about 58 MiB, 79 MiB and 42 MiB. Ten seconds of 1080p MOV is around 1.37 GB.
This is why the tool refuses a render it estimates above 1.6 GB instead of letting the tab die on the wasm heap. Against that ceiling, 1080p at 30 fps buys about 12.6 seconds of MOV, 9.2 of MKV and 17.3 of APNG; at 720p, roughly 28, 21 and 39. The message tells you to trim the clip, lower Long edge, or pick MP4 or GIF — in that order, because only the first two keep your alpha.
The refusal is arithmetic, not a verdict on your machine. A browser tab has a hard memory ceiling and a two-gigabyte MOV is not going to fit inside one. Trim first, then render.
Why the quality slider ignores three of the options
Quality maps to a CRF value for H.264 and nothing else. The tool computes 34 − (quality ÷ 100) × 16, so the slider runs from CRF 34 at zero to CRF 18 at one hundred. MOV, MKV and APNG are lossless and have nothing to trade, so moving that slider changes nothing about them.
The same applies to the bitrate table on the tool page: it describes MP4 and GIF. If you are sizing an alpha export, use frames × pixels × bytes per pixel instead, and expect the answer to be large.
Two failures that look like a bug
"This format cannot store transparency." You picked MP4 or GIF with the background set to transparent. The export stops instead of quietly compositing your subject onto something you did not choose. Set a background colour, or switch to MOV, MKV or APNG.
"A still image cannot be written into a video container." You loaded a photograph rather than a clip and picked a video format. PNG or WebP is the pair that fits, and both keep the alpha.
The download is named greenscreen-removed.apng. Some desktop tools do not recognise the .apng extension even though the bitstream is a PNG. Renaming the file to .png changes nothing about the data and is safe to do.
Choosing in one pass
Going into a desktop editor, where you will keep working on the matte: MOV. It opens everywhere, keeps full colour resolution, and costs nothing in compatibility.
Has to play in a browser, a deck or a message thread: APNG. No codec, no plugin, and it loops by default.
Archiving a master, with disk to spare: MKV. FFV1 is the only mathematically lossless option of the three.
Social upload: MP4, with the background you actually want — no container those platforms accept carries alpha.
If another tool offers you transparent WebM, run the half-transparent frame test before you believe it.
Related questions
Can I get a transparent MP4?
No. MP4 here is H.264 in yuv420p, which has no alpha plane, and the tool refuses a transparent MP4 rather than baking in a background you did not pick. Send MOV or APNG to anyone who needs the cut-out itself, and MP4 only once a background is part of the design.
Why is my transparent export dozens of times bigger than the MP4 of the same clip?
H.264 throws away what it predicts you cannot see; the alpha formats are lossless and every pixel has to come back exactly, including the partial alpha along the edge. At 1080p and 30 fps that is roughly 130 MiB per second against 24 MiB. Trim the clip or lower Long edge before lowering your expectations.
My editor will not open the APNG file. What now?
Rename it from .apng to .png — the bitstream is a PNG with animation chunks and the extension is cosmetic. If it still refuses, export the same clip as MOV instead.
Does the alpha survive if I re-encode the export?
Only if the next container has an alpha channel and the encoder actually carries it. Re-encoding a MOV into MP4 loses it; re-encoding into another alpha format keeps it. That is also why this tool decodes every frame and encodes once rather than copying streams, since a stream copy drops the alpha here.