Short answer: a JPG cannot store an alpha channel, and its 4:2:0 colour stage smears green about two pixels into the subject before you key anything. Measured with this site's own keying formula, a high-quality 4:2:0 JPG left 2,021 green edge pixels against 284 for the same frame saved 4:4:4 — 7.1 times more. Key at 22%, despill, then export PNG.
Just want the tool? Open the browser keyer, load the JPG, start at 22% / 3%, then use the despill step below. The rest of this page is the measurement behind those numbers.
What a JPG does to a green screen
Three separate losses happen before the file reaches a keyer. The alpha channel is gone, because JPEG has no way to store one. The image is split into 8×8 blocks and each block is compressed, so a hard edge between green and hair becomes a soft, block-aligned transition. And in the usual 4:2:0 profile, colour is stored at half the width and half the height of brightness: one chroma sample now covers a 2×2 group of pixels, which is exactly where a two-pixel green fringe comes from.
To separate those losses I built one 800×600 frame (green backdrop #00b140, skin, white shirt, dark hair and 44 thin strands, edges supersampled 4×4), saved it through FFmpeg 9.0.2 at several settings, decoded every file back to raw RGB, and ran the same distance-and-alpha formula the keyer on this site uses. The frame has 385,477 background pixels, 91,167 subject pixels and 3,356 mixed edge pixels.
| File | FFmpeg setting | Bytes | PSNR | Green edge px | Subject lost at 22%/3% |
|---|---|---|---|---|---|
| PNG (reference) | -c:v png | 19,162 | ∞ | 120 | 0 |
| JPG 4:4:4 | -q:v 2 -pix_fmt yuvj444p | 34,224 | 48.76 dB | 284 | 0 |
| JPG 4:2:0 | -q:v 2 -pix_fmt yuvj420p | 21,359 | 38.66 dB | 2,021 | 0.044% (40 px) |
| JPG 4:2:0 | -q:v 4 | 15,465 | 38.02 dB | 2,309 | 0.104% (95 px) |
| JPG 4:2:0 | -q:v 10 | 9,979 | 36.29 dB | 2,906 | 0.328% (299 px) |
| JPG 4:2:0 | -q:v 16 | 7,869 | 34.97 dB | 4,171 | 0.639% (583 px) |
“Green edge px” counts subject pixels within three pixels of the silhouette whose green channel exceeds both red and blue by more than 20 levels — visible green cast, not a rounding difference. “Subject lost” counts pixels that are solid in the source but come out below full opacity. -q:v 2 is FFmpeg's highest-quality MJPEG setting, not a JPEG quality number from another program.
The first surprise is what did not fail. At 22% tolerance the backdrop reached zero in every file, including the worst one; the leftover background was 0.01% at q16, about 38 pixels. A uniform green screen survives JPEG because the whole patch shifts together. The subject does not, because every hair strand and shoulder edge is a mix of green and skin, and 4:2:0 averages that mix across two pixels before the keyer sees it.
Why a higher tolerance cannot fix a JPG edge
Tolerance moves the alpha cutoff; it does not repaint a pixel. A fringe that is genuinely green stays genuinely green whether the cutoff is 22% or 40%, and raising the cutoff only deletes more of the mixed pixels you wanted to keep. On the q2 4:2:0 file the measured cost was steep:
| Tolerance (softness 3%) | Background left | Subject lost | Edge pixels kept partial |
|---|---|---|---|
| 22% | 0 | 0.044% (40 px) | 14.18% |
| 30% | 0 | 1.925% (1,755 px) | 1.52% |
| 40% | 0 | 20.30% (18,507 px) | 0% |
At 40% one fifth of the solid subject edge is gone, the soft edge is gone, and the green cast is exactly where it was. That is the whole argument against the common “use 30–40% for JPEG” shortcut: it answers a background that will not clear, not a subject that keeps a green rim. If the backdrop itself is mottled, a wider tolerance can be the right call — but decide that from the checkerboard, not from the file extension.
Sampling the JPG's own green is still worth doing, though on this clean test it barely moved the numbers: the saved background read #00b13f instead of #00b140, and the subject loss went from 0.044% to 0.045%. On a real photograph the shift is larger because white balance, lighting and skin tones all pull the average; the sample is a correction, not a cure.
The order that works: key, despill, export PNG
- Keep the camera original if it exists. A JPG is already damaged; converting it to PNG afterwards preserves the damage, it does not undo it.
- Key at 22% / 3% as a starting point. Load the JPG into the browser keyer, click a clean patch of green, and judge the result on the checkerboard. Tighten tolerance if the subject thins; widen it only if background remains.
- Despill after the key. The clamp
g′ = g − max(0, g − max(r,b))removes the green cast without touching alpha. On the q2 4:2:0 file it took the green edge count from 2,021 to 0 and the maximum green excess from 92 to 0; subject loss went from 0.044% to 0 because the repainted pixels are now further from the key colour. The working tool and its limits are on green screen remover spill. - Export PNG, never JPG. The keyer writes a PNG because that is the only common web format here that carries the alpha you just built.
- Check the alpha on white and on black. A fringe that disappears on one background can be obvious on the other. The counting checker is on green screen remover edge check.
That order matters. Despilling before keying changes the backdrop too: the measured backdrop #00b140 becomes #004040, which is 25.58% away from the key instead of 0%, so the background comes back as opaque. Key first, then fix colour.
Two things that make a JPG edge worse
Re-saving the same JPG
JPEG is lossy at every save, including a save at the same quality. Four consecutive q2 4:2:0 saves of the same frame, each decoded and re-encoded, produced this:
| Save | Bytes | PSNR vs original | Green edge px | Subject lost |
|---|---|---|---|---|
| 1 | 21,359 | 38.66 dB | 2,021 | 0.044% |
| 2 | 21,084 | 36.94 dB | 2,451 | 0.129% |
| 3 | 20,910 | 35.13 dB | 2,594 | 0.171% |
| 4 | 20,872 | 33.50 dB | 2,714 | 0.203% |
Each pass adds between 120 and 430 green edge pixels — the first re-save adds the most — and removes a little more of the soft edge. The file also gets slightly smaller each time, which is the tell: the encoder is throwing away detail, not preserving it.
Blurring the colour channels before keying
It is a tempting repair — smooth the chroma, then key the smoothed image. Measured, it moved the wrong way: a one-pixel chroma blur raised the green edge count from 2,021 to 3,410, and a two-pixel blur raised it to 4,364. Blurring spreads the green further into the subject before the key sees it. The same blur also lowered the number of partially transparent edge pixels, so the matte got harder while the fringe got wider.
If you control the export, ask for 4:4:4 and the highest quality. At q2 the 4:4:4 file was 60.2% larger (34,224 vs 21,359 bytes) and left 86% fewer green edge pixels (284 vs 2,021). That is a better trade than any post-processing step tested here.
Green screen remover JPG FAQ
Why does my keyed JPEG sequence have a green halo when it looked perfect in After Effects?
Because the alpha you saw in the timeline was never in the JPEG. One editor described keying two JPEG sequences, seeing a perfect result in After Effects, then re-importing the exported JPEGs and getting a green halo. A JPEG sequence carries colour only: the alpha is either a separate black-and-white sequence or it is gone. Re-importing then composites the colour against whatever the alpha channel says, and the green that was hidden in the semi-transparent edge becomes visible. Export a format that carries alpha (PNG, TIFF, ProRes 4444) or key after the re-import, and keep the 4:2:0 damage in mind: at q2 it was 2,021 green edge pixels against 284 for 4:4:4.
Can a JPEG have a transparent background?
No. The JPEG format has no alpha channel, so there is nowhere to store transparency. Saving a keyed image back to JPG replaces transparent pixels with a solid colour — usually white or black — and the green fringe you removed comes back as opaque pixels. That is why every export button on this site produces PNG. If a page offers a “transparent JPG”, it is either producing a PNG with a different name or flattening the transparency onto a colour and calling that the background.
Is 30–40% tolerance the right setting for a JPG?
Not by itself. On the measured q2 4:2:0 frame the backdrop cleared at 22%, while 30% deleted 1.9% of the subject and 40% deleted 20.3% — and neither value changed the green cast on the edge, because tolerance only changes alpha. Use a wider tolerance when the background itself is uneven or shifted, and use despill when the background is gone but the subject is green. Those are two different faults and they need two different controls.
Does saving at maximum JPG quality keep the edge clean?
Only if the encoder also stops subsampling colour. FFmpeg's highest-quality MJPEG setting (-q:v 2) still produced 2,021 green edge pixels in 4:2:0, 7.1 times the 284 produced by the same setting in 4:4:4. Quality and chroma subsampling are separate switches: quality controls how much detail the 8×8 blocks keep, subsampling controls how much colour resolution exists in the first place. Look for a 4:4:4 or “no chroma subsampling” option, not just a higher quality number.
Can the browser keyer open a JPG, and what comes out?
Yes. The file input accepts anything the browser can decode, including JPG, and the page draws it at up to 1400 px on the long edge. The output is always a PNG with alpha, because that is the only way to keep the transparency. Nothing is uploaded: the file is read locally, keyed in memory and downloaded from the same tab. The size limit and the tiling workaround for larger images are on green screen remover without upload.
Does this page remove green from a JPG video frame or an MP4?
The keyer works on one still image. It does not decode an MP4, and a JPG frame exported from a video is still a still image: key it, keep the PNG, then rebuild the clip. For the video path — frame sequences, FFmpeg, and which containers actually carry alpha — use green screen remover for video. The compression story repeats there: a video codec's 4:2:0 stage does the same thing to every frame that JPEG does to one.
What this test is, and what it is not
It is one synthetic 800×600 frame, one encoder (FFmpeg 9.0.2 MJPEG), and the site keyer's exact formula run outside the browser on decoded RGB. It is not a survey of every camera, every JPEG encoder, or every photograph. A real phone JPG has noise, white balance drift and an uneven backdrop, all of which can push the numbers up; a studio export at 4:4:4 can push them down. The direction is what transfers: chroma subsampling damages the subject edge, tolerance cannot repaint it, despill can, and re-saving adds more.
The script and the raw measurements are kept with the site's working files (jpg-compression-20261031.js, jpg-compression-20261031.json), and the four-panel image above is the keyer output at 22% / 3%, not an illustration.
Next step
Open the green screen remover, load the JPG, and key it at 22% / 3%. If the background is clear and the edge is green, go to the despill step; if the background is still patchy, measure the backdrop first with the tolerance guide. Then export PNG and check it with the edge checker.