Why does the export pull a background in even with transparency turned on?
The switch only turns off our compositing step; it cannot add an alpha channel the codec does not have. When the encoder has nowhere to put transparency, it writes the colour that is already stored behind the subject, and in this tool that is the screen you just keyed out — measured at (0,130,64) with alpha 0 before encoding, and (0,129,62) at full opacity after an H.264 export. So a failed transparent export is usually green, not black: black only appears if something blanked the colour first, which we measured at (0,0,0).
What the transparency switch actually controls
Two things have to happen for a transparent file to come out the other end: the keyed subject has to be left on transparency instead of flattened onto a colour, and the encoder has to be given a container and pixel format with room for a fourth channel. The switch on this page governs only the first. Set the background to transparent and our compositing step returns early, leaving the canvas holding whatever the keyer produced, alpha included.
The second half is decided entirely by the output format. In the format table behind this page every video entry is flagged as keeping alpha or not: MOV with qtrle in argb, MKV with ffv1 in yuva420p and APNG keep it, while H.264 and the GIF palette writer do not. No switch can talk a codec out of that.
The round-trip we ran
We built one second of 640x360 footage — 12 frames at 12 fps — as a neutral subject against a #00B140 screen, ran it through this page's keyer at the default settings and wrote each frame out as RGBA. On the first frame 161,233 pixels key out completely, 70.0% of the picture, 68,575 are solid subject, and 503 sit in the soft rim between them at a mean alpha of 0.489.
Then we encoded the same 12 frames into every format on the menu, plus two that are not, and decoded the first frame back, recording the pixel format each file reports, the colour where the subject used not to be, and what happened to those 503 rim pixels. Nothing below is estimated.
Which containers come back with their alpha
Three survive intact. MOV with qtrle in argb, MKV with ffv1 in yuva420p and APNG all read back with an alpha plane, the clear region still holding (0,130,64) at alpha 0, and the rim returning at a mean alpha of 0.487 against 0.489 going in — a difference of 0.002, which is rounding, not damage.
The others do not. H.264 in MP4 reports yuv420p: no alpha plane, and decoding with alpha forced on returns 255 for every pixel. The clear region is still (0,129,62), the rim is 100% solid, and the mean alpha change across those pixels is 0.511. VP9 in WebM behaves identically, as does H.264 written into a file called .mov — 4,568 bytes, alpha gone. The extension is not the guarantee, the codec is.
GIF is a third case: it carries transparency, but only as one bit, so 46.7% of the rim pixels came back solid and 53.3% fully erased, a mean change of 0.254 that turns the soft edge into a staircase. The colour behind the subject is not the screen either — the whole clear region reads (255,255,255), because the palette has one index to spare for it.
Why the background that comes back is green and not black
Our keyer writes the mask into the alpha byte and, apart from the despill limiter, leaves red, green and blue alone. So the pixels nobody is meant to see still carry the screen, desaturated to (0,130,64) at the default spill and shrink settings — hex #008240.
Drop the alpha plane and that stored colour is all the file has left, which is why the H.264 and VP9 exports read back at (0,129,62), a green excess of 66.8 levels over max(R,B). To confirm where it comes from we ran the same MP4 with the curtain blanked out of RGB first: the clear region then reads (0,0,0). Black means the alpha was dropped after something cleared the colour; green means it was dropped while the screen was still in there.
The soft edge goes with it
A partial alpha is a number between 0 and 255, and a codec with no alpha channel has nowhere to keep it. On our 503 rim pixels H.264 and VP9 made every one solid — 0.489 in, 1.000 out — so the feathered edge becomes a hard cut around whatever colour was stored there, (45,139,90), a darker green than the curtain.
GIF loses the same information differently: half the rim is promoted to solid, half thrown away, and the survivors read back at (159,202,180) instead of the original (46,142,91) — a pale halo. Neither is a keying failure. Both are 503 pixels squeezed into a channel that cannot hold fractions.
Why WebM is not on the format menu
It is missing on purpose. Asking this build for VP9 with -pix_fmt yuva420p produced a file that reads back as yuv420p: the alpha plane does not survive, and what you get is a WebM quietly shipping the curtain as an opaque background. We re-ran it on a desktop build to rule out a wasm quirk — same answer, 8,574 bytes of green.
A button labelled transparent that produces that file would be worse than no button.
What happens here instead of a silent bake
Pick an animated format that cannot keep alpha while the background is set to transparent and the render never starts: the entry point checks the format flag against the background mode and throws, telling you to choose a background colour or image, or to pick MOV, MKV or APNG. The warning pane above the button says the same thing before you press anything — for MP4, that the subject will be composited onto your background; for GIF, that partial transparency cannot be stored.
That moves the failure to the moment you can still fix it, instead of letting it surface after the file has been handed on.
Reading a file you already exported
You can tell which happened without guessing. Ask the file what pixel format it carries; if the answer has no letter a in it, there is no alpha and nothing downstream will bring it back. Then sample a pixel where the subject is not: green near (0,130,64) means the alpha plane was dropped while the screen was still stored, black means the colour was cleared or premultiplied first, and white with a stepped edge means GIF.
The fix follows from that. With no alpha plane, re-export as MOV, MKV or APNG, which returned the alpha untouched here at 515,792, 108,122 and 218,989 bytes for the same second of footage. If the destination insists on MP4, pick a background colour or image here so the flattening is your decision rather than the encoder's.
Related questions
Does a .mov file always keep transparency?
No. Ours does because it is encoded with qtrle in argb, which measured a clean round-trip. H.264 in a file with the same extension produced 4,568 bytes that read back as yuv420p, with no alpha plane. The container name tells you nothing; the codec and pixel format do.
Why is my transparent export green instead of black?
Because the keyer writes only the alpha byte and leaves the colour channels alone, so the pixels behind the subject still hold the screen at (0,130,64) after despill. A codec with no alpha channel has nothing to hide them with. We measured black only when the curtain was cleared out of RGB first.
Can MP4 carry a transparent background?
Not in the form this page can produce. H.264 reported yuv420p, meaning no alpha plane, and the clear region came back opaque at (0,129,62). Use MOV, MKV or APNG when the cut-out has to stay transparent, or set a background colour here if MP4 is what you must deliver.
Why is there no WebM option if VP9 supports alpha?
It does not survive here. Encoding VP9 with yuva420p produced a file that reads back as yuv420p on both the wasm build and a desktop build, so a transparent WebM from this tool would ship the curtain as an opaque background. The option stays off the menu rather than lying to you.