Why your transparent video turns black: I tested WebM alpha, ProRes 4444 and HEVC alpha in Chrome, Firefox, Edge and OBS

Search for "transparent video" and you'll find plenty of confident compatibility tables. Most of them don't say whether anyone actually played the file. I wanted one where every cell answers a simpler question: did someone check this, and how?

So I encoded the same 4-second clip five ways, put each one over a solid magenta background, and read the pixels back. The rule for the table: a cell is either tested (by me, with versions and a date), per official docs (with a link to the vendor's own words), or not tested. No guessing to fill gaps.

That rule leaves a lot of cells empty, and I think the gaps are useful too. If you can fill one in from macOS or Windows, please do it in the comments.

TL;DR

• Web (Chrome, Firefox, Edge): WebM VP9 with alpha kept transparency in all three (tested, Linux).
• OBS: WebM VP9 alpha and ProRes 4444 both kept transparency through a Media Source (tested, OBS 30.2.3 on Linux).
• H.264 MP4 never has alpha. It plays, and the transparent area comes out black (tested). Asking x264 for yuva420p doesn't help; it quietly falls back to yuv420p.
• Safari + WebM alpha: WebKit's own bug tracker describes it as playing "with a grey background rather than transparent" (per docs, not tested by me).
• HEVC with alpha: Apple documents it for Safari on iOS 13 / macOS Catalina and later. I could not test it, because libx265 on Linux silently drops the alpha plane. More on that below.
• Editors (Premiere, Resolve, After Effects, Final Cut Pro): vendor docs point to ProRes 4444 for alpha. I didn't run import tests in any editor.

The test setup

Everything ran on 2026-09-24 on one machine:

Item	Version
OS	Debian GNU/Linux 13 (trixie), x86_64
ffmpeg	7.1.5-0+deb13u1
Chrome	151.0.7922.169
Firefox	153.0 (Playwright build)
Edge	153.0.4234.48
OBS Studio	30.2.3 (X11)

The source clip is synthetic: ffmpeg drew a cyan circle on a fully transparent background, 320×180, 4 seconds. A synthetic clip makes the check easy. The corner pixel should be fully transparent and the circle fully opaque, so there's nothing in between to argue about.

Encodes (the exact commands I ran)

# WebM VP9 with alpha
ffmpeg -y -i source-synthetic.mov -an -c:v libvpx-vp9 -pix_fmt yuva420p \
  -auto-alt-ref 0 -deadline good -cpu-used 4 -b:v 0 -crf 33 -t 4 01-webm-vp9-alpha.webm

# HEVC "with alpha" attempt (spoiler: no alpha in the output)
ffmpeg -y -i source-synthetic.mov -an -c:v libx265 -pix_fmt yuva420p -t 4 02-hevc-alpha-attempt.mov

# ProRes 4444 with alpha (profile 4 = 4444)
ffmpeg -y -i source-synthetic.mov -an -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -t 4 03-prores4444-alpha.mov

# H.264 MP4 control (no alpha by design)
ffmpeg -y -i source-synthetic.mov -an -c:v libx264 -pix_fmt yuv420p -preset fast -crf 23 -t 4 04-mp4-h264-noalpha.mp4

# PNG sequence (RGBA)
ffmpeg -y -i source-synthetic.mov -an -vf format=rgba -start_number 0 05-png-seq/frame_%04d.png

Browser check: magenta stage + canvas pixel read

A local HTTP page put each file inside a <div> with background: #ff00ff. Playwright drove Chrome, Edge and Firefox. Once the video played, the page seeked to 0.1 s, painted magenta onto a canvas, drew the video frame over it, and sampled two pixels: a corner (should be transparent) and the circle (should be cyan).

ctx.fillStyle = '#ff00ff';
ctx.fillRect(0, 0, 320, 180);
ctx.drawImage(video, 0, 0, 320, 180);

const corner = ctx.getImageData(10, 10, 1, 1).data; // transparent area
const circle = ctx.getImageData(40, 90, 1, 1).data; // opaque area
// corner ≈ [255, 0, 255] → alpha kept (magenta shows through)
// corner ≈ [0, 0, 0]     → no alpha (black)

Real readings from Chrome 151: the WebM corner was [255, 0, 255, 255]. The H.264 MP4 corner was [0, 0, 0, 255]. Same clip, same page.

OBS check: Color Source + Media Source

In OBS I put a magenta Color Source at the bottom of the scene and a Media Source pointing at the test file above it, then took a screenshot of the preview. If alpha survives, you see a cyan circle on magenta. If it doesn't, you see a black rectangle.

Results

Legend: ✅ tested = I ran it, on Linux, 2026-09-24, with the versions above. 📄 docs = the vendor's own documentation says so (footnote links); not tested by me. — not tested = no test and no usable official statement, so I'm not claiming anything.

Browsers

Format	Chrome 151	Firefox 153	Edge 153	Safari (macOS)	Safari (iOS)
WebM VP9 + alpha	✅ alpha kept	✅ alpha kept	✅ alpha kept	📄 plays, grey bg instead of transparent [1]	— not tested [2]
HEVC + alpha	— not tested [3]	— not tested [3]	— not tested [3]	📄 supported (Catalina+) [4]	📄 supported (iOS 13+) [4]
ProRes 4444 MOV	✅ won't play	✅ won't play	✅ won't play	— not tested	— not tested
H.264 MP4 (control)	✅ plays, black bg	✅ plays, black bg	✅ plays, black bg	— not tested	— not tested
PNG sequence	✅ N/A as <video>; frame via <img> keeps alpha	✅ same	✅ same	— not tested	— not tested

OBS and editors

Format	OBS 30.2.3	Premiere Pro	DaVinci Resolve	After Effects	Final Cut Pro
WebM VP9 + alpha	✅ alpha kept	— not tested	— not tested	— not tested	— not tested
HEVC + alpha	— not tested [3]	— not tested	— not tested	— not tested	— not tested
ProRes 4444 MOV	✅ alpha kept	📄 imports ProRes; 4444 carries alpha [5]	📄 ProRes decode Yes; alpha exports 4444 [6]	📄 ProRes import/export; 4444 carries alpha [7]	📄 imports all ProRes; use 4444 to preserve alpha [8]
H.264 MP4 (control)	✅ plays, black inside the frame	— not tested	— not tested	— not tested	— not tested
PNG sequence	— not tested	📄 PNG import listed; sequence alpha not stated [9]	📄 png decode/encode Yes [6]	📄 PNG import; stills importable as sequence [7]	📄 PNG stills supported [8]

Count: 50 cells. 15 tested, 11 per official docs, 24 not tested.

The "✅ won't play" cells are real results, not failures of the test. Chrome and Edge returned DEMUXER_ERROR_NO_SUPPORTED_STREAMS for the ProRes MOV. Firefox returned NS_ERROR_DOM_MEDIA_DEMUXER_ERR. ProRes is an editing format, not something to put on a web page.

Sources for 📄 cells

1. Safari 14.1 release notes: "WebKit on macOS supports WebM files containing VP8 or VP9 video tracks" (webkit.org). For alpha, WebKit bug #275908, "VP9 with transparency plays back incorrectly … with a grey background rather than transparent", status NEW when I checked (bugs.webkit.org).
2. The bug doesn't say whether it covers iOS, and the Safari 14.1 WebM paragraph is about macOS, so I'm not extending either one to iOS.
3. I couldn't produce a real HEVC-with-alpha file on Linux. See the next section.
4. Apple WWDC19 session 506: "HEVC video with Alpha is supported by Safari in iOS 13 and macOS Catalina" (developer.apple.com). See also Using HEVC video with alpha.
5. Adobe lists Apple ProRes as a supported native format (helpx.adobe.com). Apple: ProRes 4444 and 4444 XQ "are also the only Apple ProRes codecs that support alpha channels" (support.apple.com/102207).
6. DaVinci Resolve 20 Supported Codec List: Apple ProRes, mov/mkv, Alpha Exports: 4444, Decode: Yes. png: Decode/Encode Yes (PDF).
7. After Effects supported formats: "Apple ProRes codec — Import and Export", "Portable Network Graphics (.png)", and "You can import files of any still image format as a sequence" (helpx.adobe.com). The alpha part comes from Apple 102207, as in [5].
8. Final Cut Pro supported media: "Apple ProRes (all versions)", PNG under still-image formats (support.apple.com). Apple's FCP transcoding note: "To preserve the alpha channel, choose ProRes 4444 or ProRes 4444XQ" (support.apple.com/101763). For compositing see Use alpha channels.
9. Premiere's supported-formats page lists PNG. I found no Adobe sentence that says sequence alpha is preserved, so I'm not claiming it.

ffprobe will mislead you twice

1. A VP9 file with alpha reports yuv420p. This is the ffprobe output for the WebM that kept alpha in every browser above:

"codec_name": "vp9",
"pix_fmt": "yuv420p",
"tags": {
  "alpha_mode": "1",
  "ENCODER": "Lavc61.19.101 libvpx-vp9"
}

If you only grep for yuva, you'll decide this file has no alpha, and you'll be wrong. For WebM, look for the alpha_mode=1 tag, then confirm with a visual composite test like the one above.

2. x264 and x265 accept a yuva request and silently ignore it. I asked for alpha three times and got none:

Command asked for	ffprobe reported	Alpha?
libx264 -pix_fmt yuva420p	yuv420p	No
libx265 -pix_fmt yuva420p	yuv420p (Main)	No
libx265 -pix_fmt yuva444p10le	yuv444p10le (Rext)	No

The ProRes encode was the opposite case: I asked for yuva444p10le and ffprobe reported yuva444p12le, profile 4444, tag ap4h. The alpha survived, and the decoder just reports the 12-bit pixel format. In short, when an encoder can store alpha, ffprobe shows a yuva format. When ffprobe shows yuv with no alpha tag, the alpha is gone.

Why I couldn't test HEVC with alpha on Linux

Apple's HEVC-with-alpha format isn't simply "HEVC with an extra channel." According to WWDC19 session 506, each frame carries two layers inside a single video track, a base color layer and an alpha layer, using special HEVC syntax. Apple says encoding goes through AVFoundation / VideoToolbox (AVAssetWriter, export presets "with Alpha", or VTCompressionSession).

On Linux I have libx265, which (as shown above) drops the alpha plane without raising an error. I don't have VideoToolbox there. So my "HEVC alpha" file was really ordinary opaque HEVC, and testing it would only show how browsers handle opaque HEVC. For the record, Chrome and Edge refused to play it, and Firefox played it with a black background. That's why every HEVC cell in my browser and OBS columns is not tested, and the Safari cells rely on Apple's documentation.

The same talk explains why a "working" HEVC alpha file can still lose its transparency somewhere else: an HEVC decoder "that does not know how to handle the Alpha layer will ignore it and display the base layer alone." The file plays, but the alpha layer is skipped.

Serving one overlay to every browser

MDN documents how <source> fallback works: "The browser goes through a list of <source> elements to find a format it supports. It uses the first one it can display" (MDN). The usual pattern pairs an HEVC-alpha file for Safari with a WebM VP9 alpha file for everyone else:

<video autoplay muted loop playsinline>
  <!-- HEVC with alpha (encoded on macOS) — Safari per Apple docs; NOT tested by me -->
  <source src="overlay-hevc-alpha.mov" type="video/quicktime">
  <!-- WebM VP9 alpha — tested: Chrome 151 / Firefox 153 / Edge 153 on Linux -->
  <source src="overlay-vp9-alpha.webm" type="video/webm">
</video>

Two caveats, both based on the documents above rather than on a test of my own. First, the order matters, because the browser takes the first source it can play. Second, per the WWDC note, a browser that can decode HEVC but not the alpha layer would show the opaque base layer. Before you ship this, open it in every browser you care about, on the operating systems your users actually run. I haven't run this snippet, so I can't tell you which source each browser picks.

Pick the format by destination

Destination	Use	Basis
Chrome / Firefox / Edge <video>	WebM VP9 alpha (yuva420p)	✅ tested (Linux)
Safari <video>	HEVC with alpha, encoded with Apple tools	📄 Apple WWDC19 506; not tested
OBS Media Source	WebM VP9 alpha or ProRes 4444	✅ tested (OBS 30.2.3, Linux)
Premiere / Resolve / AE / Final Cut	ProRes 4444 MOV	📄 vendor + Apple docs; not tested
Anything where you need alpha	Not H.264 MP4	✅ tested: black background

"My transparent video turned black": a checklist

Each item points to its evidence:

1. The file never had alpha. H.264 MP4 has no alpha. ✅ In Chrome, Firefox, Edge and OBS the transparent area rendered black.
2. Your encoder dropped the alpha without telling you. x264 and x265 both did this (the table above). Check with ffprobe.
3. You exported ProRes, but not 4444. Apple: only ProRes 4444 and 4444 XQ support alpha. 📄
4. WebM VP9 alpha in Safari. WebKit #275908 describes playback "with a grey background rather than transparent". 📄 (I haven't seen it myself; Safari isn't in my test.)
5. HEVC alpha in a decoder that doesn't know about the alpha layer. Per Apple, it shows the base layer only. 📄
6. The editor interprets the alpha differently. Saying an editor "supports ProRes" doesn't tell you whether it treats alpha as straight or premultiplied by default. If edges or backgrounds look wrong after import, check the footage interpretation settings (Interpret Footage in Adobe apps) before you blame the file.

Caveats

• Linux only. Chrome, Firefox, Edge and OBS ran on Debian 13. Don't assume the same results on macOS, Windows or mobile, where decoders and GPU paths differ.
• OBS used software GL (X11 + llvmpipe). Hardware decoding paths may behave differently.
• Synthetic clips. The test files came from ffmpeg, not from any particular app's export pipeline.
• "Per docs" isn't a test. I quoted vendor documentation exactly and linked it, but I didn't open Premiere, Resolve, After Effects or Final Cut Pro.
• PNG sequences aren't a <video> format. The browser cells only show that a single RGBA frame kept alpha when drawn with <img>.

What I haven't tested yet (help wanted)

These are the 24 empty cells, grouped:

• Safari on macOS and iOS: every format. I have no Safari results of my own, including WebM alpha (only the WebKit bug above) and HEVC alpha (only Apple's docs).
• Real HEVC with alpha anywhere: it needs an encode from VideoToolbox on a Mac.
• WebM VP9 alpha in Premiere, Resolve, After Effects and Final Cut Pro
• H.264 MP4 in all four editors and in Safari (expected to have no alpha, but nobody has checked)
• PNG sequence in OBS (Image Slide Show or similar)
• macOS and Windows builds of Chrome, Firefox, Edge and OBS

If you can run the magenta test on any of these, post the app version, OS, file type and what you saw in the comments. I'll update the table and credit you.

How I produce these files day to day

Disclosure: I build ExportAlpha. It's a browser tool that removes the background from a video and exports it as WebM VP9 with alpha (yuva420p, clips up to 60 seconds) or ProRes 4444 MOV (up to 8 seconds), which are the two formats that passed the OBS test above. It doesn't export HEVC with alpha, so for the Safari row you'll still need Apple's tools. The test clips in this post were made with plain ffmpeg, not with ExportAlpha, so the matrix doesn't depend on my product. The full matrix, with per-cell notes, is also published here.

If you've been fighting a black box behind a "transparent" overlay, I'd like to hear which app and format it was. Questions about the Playwright and canvas setup are welcome in the comments, too.

Drafted with AI assistance; every test result comes from the run described above, and each cited claim links to its source.