Transparent WebM

A WebM is a Matroska container holding VP8 or VP9 video. Both of those codecs can carry a fourth value per pixel — how opaque it is — and most trouble comes from that value being dropped between the encoder and the screen. What it is, where it survives, how to check.

What the alpha channel actually is

Ordinary video stores three numbers per pixel: red, green and blue. A transparent WebM stores a fourth, the alpha, running from 0 (fully invisible) to 255 (fully solid). It rides alongside the colour planes in the same bitstream, which is why the codec matters: VP8 and VP9 have an alpha mode, and a WebM written with a codec that does not is just a rectangle.

The values in between are the ones worth caring about. A cut-out that only knows “there” and “gone” is what gives keyed footage its cut-with-scissors outline. This keyer produces a continuous alpha: inside the tolerance band, a pixel’s opacity is proportional to how far its colour sits from the key colour, so hair, motion blur and soft fabric keep a graded edge. The band only exists when the Edge slider is above zero. At zero and below it closes, and every pixel snaps to fully on or fully off.

Three places the alpha gets dropped

1. At encoding. The encoder has to be asked for a codec with an alpha mode. If it is not, the frames are flattened onto a background before the first byte is written, and nothing downstream can recover what was never stored.
2. At playback. A player that ignores alpha composites the frames against something, usually black. The file is intact; the player is not reading it.
3. On upload. Any service that re-encodes to H.264 destroys the alpha on the way in. If a platform does not document an alpha-friendly format, assume the transparency will not survive.

What this tool writes

Exporting a transparent WebM here is a recording, not an encode. The page draws each keyed frame onto a canvas, calls captureStream at 30 fps on that canvas, and hands the stream to MediaRecorder. Concretely, the export:

• asks for video/webm;codecs=vp9, and falls back to plain video/webm where that string is not supported;
• targets about 8 Mbps;
• rounds the frame dimensions down to an even number, which is what VP9 requires;
• runs in real time — there is no video encoder in the page, so a sixty-second clip takes about sixty seconds;
• saves as <your-file>-transparent.webm.

Without MediaRecorder or captureStream, the WebM button is hidden rather than offering an option that cannot work; the PNG sequence is the fallback. The video page covers the same exports from the shooting side.

The file has no duration, and why that bites

A WebM written by MediaRecorder carries no duration in its header. The browser reports the length as infinity until something forces a scan to the end, and an editor that trusts the header will show an unknown length, refuse to scrub, or import a truncated clip. This is a container artefact, not damaged video.

Remux rather than re-encode: copying the streams into a fresh container leaves the alpha alone, while any re-encode is a chance to lose it. Play the file once in a browser first — that is enough to make the real length appear in most tools that read it afterwards.

How to check whether the transparency survived

1. Put the file on a page or a canvas with a coloured background. A subject that floats over the colour has alpha; a subject sitting on black does not.
2. Import it into an editor and drop another clip underneath. Same test, better lighting.
3. If you have ffprobe, read the pixel format of the video stream. An entry with an alpha component means the channel is there; a plain yuv420p means it is not.

Do the test on the machine and in the version you are actually shipping to. “It played fine for me” on one browser says nothing about the player your client uses.

Where it plays, and where it does not

We have not run a compatibility matrix across players and editors, so this page reports no playback percentages. What follows is the practical shape of the problem, and every third-party entry is something to verify in the version you use:

• Browsers. Chrome, Edge and Firefox read WebM and composite the alpha when the video is played in a page. That is the environment this format was built for.
• Desktop editors. Plenty of non-linear editors do not import WebM at all and expect you to supply something else — and a transcode is exactly where the alpha dies. If the result is going onto a timeline, export the PNG sequence instead.
• Safari and iOS. WebM support there has been uneven across versions. Check on the target device rather than assuming.
• Social and messaging platforms. Unless a platform documents an alpha-friendly format, plan for the upload to be re-encoded and flattened.

When this does not work

• You need an MP4. There is no transparent MP4. No setting here or anywhere else produces one.
• Your target re-encodes uploads. Composite the clip onto the background you want before uploading, instead of relying on alpha to survive.
• Your player ignores alpha. Verify over a coloured background before concluding the export failed.
• Your editor will not import WebM. Take the PNG sequence — it is larger, but nothing can silently flatten it. It is capped at 1200 frames here, about 100 seconds at the default 12 fps.
• The duration reads as unknown. Remux with stream copy; do not re-encode to fix it.
• Your browser cannot record a canvas. There is no WebM option and the PNG sequence is the fallback.
• Long clips. Real-time recording means a long wait, and a frame dropped during recording is gone — there is no re-encode stage to recover it.
• The alpha is only as good as the matte. Uneven lighting, compression and a badly lit screen all produce a bad matte, and no container adds detail the key never had. The slider page and the benchmark cover that side.
• We have no measured player or editor numbers. The figures published in our reference repository are keying quality on synthetic fixtures, not container or player compatibility. There is no honest number to quote here, so none is quoted.

Where our published numbers come from

The measurements behind the keying claims on this site live in the CSVs of the reference repository on GitHub, and the write-up is archived on Zenodo under DOI 10.5281/zenodo.22916767. Those fixtures are synthetic 320x240 images, not real footage. They measure how well an algorithm separates a subject from a backdrop; they say nothing about containers, codecs or players, which is why this page carries none of those numbers.

To make one, the tool keys the backdrop and records the result entirely in your browser — no upload, no account, no watermark. The transparent video page compares the formats side by side.

Open the tool