Why is a transparent background coming out black — or white?
Because transparency is not a colour, it is a number, and nothing in the file says what to put behind it. A transparent PNG from this tool carries a red, green and blue value for every one of its 921,600 pixels and a separate alpha value saying how much of that colour to use — the keyer only writes the alpha byte, so the pixels behind the subject still hold the screen, measured at (2,129,64) after the default despill. A viewer that ignores the alpha shows you exactly that, green rather than black. Black or white means something flattened the file: on the same frame, compositing onto black gives (0,0,0) and onto white (255,255,255), and the semi-transparent rim, 10.4% of the frame, is what gives away which one did it.
What is actually in the file
Nothing is missing. Take one 1280x720 frame, key it with the defaults on this page, and write it out as a PNG: 781,473 pixels are fully transparent, 84.8% of the frame, 44,223 are solid, and 95,904 — 10.4% — sit in between as the semi-transparent rim. Read the file back and the alpha channel returns identical to what was written to within 1 level out of 255, which is rounding; WebP carries it just as faithfully.
So a transparent file is not a picture with a hole in it. It is a full-resolution colour image plus one more number per pixel saying how much of that colour the viewer is allowed to use. Everything that follows comes from what a consumer decides to do with that number.
The screen is still in there
The keyer on this page computes a mask from each pixel's distance to the key colour, writes that mask into the alpha byte, and leaves red, green and blue alone apart from the despill limiter. Which means the pixels nobody is supposed to see still contain the screen.
Measured over every fully transparent pixel, they average (2, 129, 64) at the default despill settings and (2, 175, 64) with despill turned off — and (2, 175, 64) is the screen you shot against. Save that PNG as a JPEG without flattening it first and the background comes out at (2, 129, 64), because JPEG has no alpha channel and the converter simply kept the colour.
This is worth knowing before you blame the export: a transparent file from this tool that loses its alpha does not go black. It goes green.
The three things a consumer can do
Given a pixel's colour P and its alpha a, there are three sane-looking ways to produce an opaque picture, and only the first is right.
Composite correctly: a × P + (1 − a) × background. Ignore the alpha and show P. Or assume the file is already premultiplied when it is not, and multiply twice: a × a × P + (1 − a) × background. The second is what happens in any pipeline that has no concept of transparency; the third is what happens when a writer and a reader disagree about whether the colour has already been scaled.
Where black comes from
If the producer multiplied the colour by the alpha before writing and the consumer then throws the alpha away, transparent pixels hold zero in all three channels and you get exactly (0, 0, 0) — a black background, with the subject fading into it. Compositing the same file onto black deliberately gives the identical result, so the two are indistinguishable from the finished picture alone.
The tell is the rim. When a file is read as straight alpha but was written premultiplied, the semi-transparent ring gets scaled twice, and the error works out to a × (1 − a) × P: zero at both ends, worst at a = 0.5, where a quarter of the stored colour is subtracted. Measured on this frame that is a mean error of 4.5 levels across the rim, 11.9 at the 95th percentile and 34.4 at worst, with 46,124 rim pixels — 48% of them — off by 8 levels or more. A mid-rim pixel storing (47, 131, 79) loses (12, 33, 20), so the outline goes dark and slightly desaturated.
The prediction and the measurement agree to the decimal: a(1−a)P gives a mean of 4.5 against 4.5 measured. That is the halo you are looking at, and it is arithmetic, not a bad key.
Where white comes from
Same mechanism, other endpoint: a pipeline that flattens onto white produces a background of exactly (255, 255, 255), and a file that was premultiplied but read as straight gets the same double-scaled rim on top of it. The rim error is identical over black and white — 4.5 mean, 34.4 max, the same 48% of rim pixels — because the background term cancels out of the difference. The rim is darker than it should be either way; against white it reads as a dirty grey-brown outline, against black as a black one.
One thing that is not a bug: compositing correctly onto white genuinely lightens the rim, because a pixel at 50% alpha is half background by definition. That brightening is the matte working. The version to worry about is the extra darkening on top of it.
The green survives the flattening
Whatever colour the file is flattened onto, the green left in the rim goes along with it. Measured on the composite rim at default despill, the green excess — G minus the larger of R and B — averages 3.3 levels and peaks at 53.6, with 2,266 rim pixels above 8, about 2% of the rim. Turn despill off and the same rim measures 5.6 mean and 91.6 at worst, with 14,856 pixels above 8 — 15% of it.
That is why a report of a black fringe is so often a report of a green fringe seen against a dark background. Flattening hides the green by mixing it, it does not remove it, and the despill slider is what holds it at 2% rather than 15%.
How to tell which one happened
Look at the dead area, not at the subject. Its colour is the fingerprint of whatever flattened the file: a checkerboard or whatever was behind means the alpha was honoured; (2, 129, 64) means the alpha was dropped and you are seeing the screen through the default despill; (2, 175, 64) means the same with despill off; (0, 0, 0) means it was composited onto black, or written premultiplied and dropped; (255, 255, 255) means composited onto white.
One caution about this page: the preview canvas sits on a dark checkerboard, #1a1f28 and #12161c, so you are judging the cut-out against near-black by default. If the destination is white, judge it there instead — this tool lets you set a background colour or image before you export, and for MP4 and GIF, which cannot carry alpha at all, it composites onto the colour you picked (white by default) and warns you first. PNG, WebP, MOV, MKV and APNG keep the alpha, and what they keep is straight alpha: the colour and the coverage are stored separately, and nothing has been pre-scaled.
Related questions
The PNG looks fine here but opens black somewhere else — is the file broken?
Almost certainly not. On this test frame the alpha came back identical to what was written, to within one level out of 255 of rounding, through both PNG and WebP. What changed is that the other program had to produce opaque pixels and made its own choice. Check the colour of the area behind the subject: (2,129,64) means it kept the stored colour and dropped the alpha, (0,0,0) means it composited onto black.
Why does the background turn green when I convert to JPEG?
JPEG has no alpha channel, so the converter kept the colour and threw the coverage away — and the colour behind your subject is still the screen, measured at (2,129,64) after the default despill. Flatten onto a colour first. This tool does that for you on MP4 and GIF, which cannot carry transparency either, compositing onto the colour or image you choose before it encodes.
Why does the edge look dark on both a black and a white background?
That is the signature of alpha being applied twice — a file written premultiplied and read as straight, or the reverse. The error works out to a x (1-a) x the stored colour, which has no background term in it, so it is the same size either way: measured here at 4.5 levels mean and 34.4 worst, with 48% of rim pixels off by 8 or more, on black and on white alike.
Is the halo a sign my key settings are wrong?
No. A double-multiplied rim is arithmetic applied after the key, and it scales with the stored colour rather than with your tolerance or despill settings. What those settings do change is the green left in the rim: measured on this frame, 2% of rim pixels above 8 levels of green excess at default despill against 15% with despill off. Fix the flattening first, then judge the edge.