Why does an alpha channel make the file so huge — and does keying green instead actually save space?
Because alpha is a fourth value kept for every pixel, and unlike colour it does not go flat anywhere. Measured on this tool's own export path at 1280x720 and 30 fps, one second came out at 13.18 MiB as the transparent MOV it writes and 10.00 MiB as the identical encode with the alpha plane removed — 1.32x, almost exactly the four-thirds a fourth byte predicts. Keeping the green and shipping the MP4 it writes at default quality cost 0.054 MiB for that same second, so yes, the saving is real: 244x. What you pay is a second keying pass on the far end, and at CRF 23 that pass misses the matte you would have exported by 0.045 mean alpha across the rim.
What the fourth channel actually costs
The clean way to measure it is to change one thing. One second of 1280x720 at 30 fps, encoded three times with the same codec: as the tool exports it, -c:v qtrle -pix_fmt argb; with the fourth plane dropped, -pix_fmt rgb24; and as the alpha plane alone, -pix_fmt gray. Results: 13.18 MiB, 10.00 MiB and 0.99 MiB.
So the alpha plane costs 3.23 MiB on that second, a factor of 1.32 — within rounding of 4/3, and not by coincidence. QuickTime Animation is a run-length codec, and where pixels stop repeating it stores them literally, four bytes where three used to be. The same test through FFV1, which has a real entropy coder behind it, went from 11.84 to 13.61 MiB: the fourth channel costs 1.15x there.
One detail in that number is easy to miss. The keyer on this page writes alpha and leaves the red, green and blue values alone apart from the spill limiter, so the transparent file still contains the screen. The green you removed is in there at alpha 0, paid for once as colour and again as the instruction to ignore it.
Where the alpha bytes actually go
Encode the alpha plane by itself and it comes to 0.99 MiB for the second. Count the pixels that are neither fully on nor fully off: 2,779,607 per second, 10.05% of every pixel in the clip. Divide one by the other and the plane is 0.372 bytes per semi-transparent pixel — the rim accounts for essentially all of it.
Inside the subject alpha is 255 everywhere, outside it is 0 everywhere, and a run-length codec collapses both to almost nothing: every byte spent on transparency goes to the one- or two-pixel outline where the two meet, which is why the file does not get cheaper when your subject fills more of the frame.
Why flat green is nearly free
Run the same second through the encoder this tool uses for MP4 — libx264, -pix_fmt yuv420p, the quality slider default of 70, which maps to CRF 23 — and the file is 0.054 MiB. That is 244x smaller than the transparent MOV of the same frames; at 1920x1080 the same pair measured 27.25 MiB against 0.088 MiB, 311x.
Encode the screen with nobody in front of it and the reason shows up: the empty screen alone is 0.035 MiB, 65% of the clip with a subject in it. Take the grain out of that screen and it drops to 0.0031 MiB, 5.7%. Per pixel of frame, 0.00133 bytes against 0.0374 for the alpha plane — the screen is 28x cheaper to store than the transparency it replaces.
It is flatness that buys that, not greenness: H.264 spends its bits on what changes, and a backdrop is the least changing thing in the shot by design. One caveat belongs next to the 244x — MP4 cannot carry alpha at all, so this is a different deliverable, not the same one at a smaller size.
How much of that is noise rather than colour
Those ratios move a lot with the condition of the screen, so the clip was run at four levels of grain. Sizes in MiB for one second of 720p30, in order: alpha MOV, alpha plane alone, MP4 CRF 23, empty screen. No grain: 2.73, 0.66, 0.028, 0.003. Grain 2.5: 13.18, 0.99, 0.054, 0.035. Grain 6: 13.25, 0.99, 0.148, 0.136. Grain 12: 13.26, 1.11, 0.267, 0.233.
Two things fall out. The alpha plane hardly moves, 0.66 to 1.11 MiB, while carrying the screen moves 78-fold, from 0.003 to 0.233 MiB: at the clean end the plane is 201x the price of the screen it replaces, at the noisy end 4.8x, with the empty screen alone 87% of the whole file.
The other is how abruptly the flat case collapses: no grain to a little costs 10.45 MiB of MOV, and a little to nearly five times as much costs another 0.08 MiB. So the honest version is not that a green screen is cheap — it is that an evenly lit, low-noise screen is cheap, which is what every article about edge quality keeps saying for a different reason.
What you pay: the key has to run again
Keeping the green means somebody downstream keys it, and that pass does not land where yours did. Compressing at CRF 23, decoding, and running this page's keyer at its defaults over the result gives a rim error of 0.0453 mean absolute alpha, against 0.0086 for keying the same frames uncompressed. The 95th percentile goes from 0.0217 to 0.1237 and the worst pixel from 0.0746 to 0.98 — flipped sides.
In pixels: 14,881 per second that were solid subject come back as holes, and 13,694 that were background come back solid, at 720p30.
The control matters: put the green version through the lossless qtrle twin and the numbers return identical to pristine, 0.0086 with no new holes or leaks, so the idea costs nothing and only the lossy encode does. If you must keep the green, CRF 18 buys much of it back — 0.0418 and 7,292 holes — for 0.177 MiB per second, three times the CRF 23 file and still 74x smaller than the transparent MOV.
Where the loss comes from
Mostly not the quantisation. Simulate 4:2:0 chroma subsampling alone — halve the colour resolution both ways, no blocking, no rate control — and the rim error goes from 0.0086 to 0.0348, with 2,456 holes and 4,390 leaks; full H.264 at CRF 23 adds only 0.0105 on top. Most of the damage is done the moment colour is stored at one sample per 2x2 block, because the key decision rests entirely on colour and there is no longer one colour value per pixel to make it on.
That sets the ceiling too: whatever you do with bitrate, an edge recovered from 4:2:0 material has half the colour resolution you started with, so a strand that was one pixel wide is not recoverable as a strand.
When to keep the green and when to keep the alpha
For a master, an archive, or a hand-off to someone who will composite themselves, keep the green: you keep the pixels you shot, the file is three quarters the size of the lossless alpha version at 720p, and nothing has been decided that the recipient may want to decide differently. Keep it lossless or lightly compressed if anyone will key it again.
For a deliverable that drops onto arbitrary backgrounds with no second pass — a web page, a deck, a game engine — pay for the alpha: the rim is resolved once, at full colour resolution, and every viewer gets that edge.
Stills show it more starkly because JPEG exists: one frame of this clip is 1,619 KiB as a transparent PNG, 1,380 KiB as the RGB PNG of the original shot, and 76 KiB as a JPEG at quality 90 — 21x smaller, screen still in it, key still to come.
This tool writes both sides. PNG, WebP, MOV, MKV and APNG carry the alpha; MP4 and GIF cannot, and it says so before you export, flattening the cut-out onto the colour or image you picked. Its size estimate is pessimistic on purpose — 2.2 bytes per pixel for MOV, 3.0 for MKV, 1.6 for APNG, 0.4 for MP4 — because it has to hold for footage with grain: on the near-clean clip here the MOV came out at 0.46 to 0.50, on the noisier clip used for the size measurements elsewhere on this site, 3.88.
Related questions
Isn't a fourth channel just 33% more data?
Measured, very nearly: 1.32x for QuickTime Animation on this clip, which is four bytes where three used to be, and 1.15x for FFV1, which compresses the plane instead of storing it. The much larger figures quoted for transparent video — 244x here — are not a four-versus-three comparison at all, they are a lossless codec against H.264. If the question is what alpha costs, the answer is about a third; if it is what a transparent deliverable costs, hundreds of times.
Which transparent format comes out smallest?
It depends on the footage, which is why the tool offers more than one. On this clean synthetic clip QuickTime Animation in MOV won narrowly, 13.18 MiB against 13.61 for FFV1 in MKV. On the noisier clip used for the size measurements elsewhere on this site FFV1 won by a wide margin, 43 MiB per second against 230 at 1080p, because it still has an entropy coder where RLE has given up. Measure your own clip rather than trusting either number.
If I ship the green version, does the other person need this exact tool?
No — any keyer will do — but they need one, and they need to know your key colour and tolerance, because nothing in the file records it. They also inherit whatever the codec took out: at CRF 23 this measurement put the re-keyed rim 0.045 away from the matte you would have exported, with roughly fifteen thousand pixels a second of 720p30 flipping to holes.
Why does the MP4 export ask for a background colour if MP4 has no alpha?
Because the cut-out has to be flattened onto something before it can be written. The tool composites the keyed frames onto the colour or image you choose, warns you that MP4 and GIF cannot store partial transparency, and points you at MOV, MKV or APNG if you need the alpha kept. You just cannot get the transparency back out of that file.