Do WebP and AVIF Support Transparency? Why Cut-Outs Come Back Black or White (and How to Fix It)

How WebP and AVIF store transparency

Both formats store transparency as a real per-pixel alpha channel, not the single "this one color is invisible" trick that GIF and paletted PNG use, so soft edges, drop shadows and semi-transparent glass all survive. The details differ, and one of them explains why AVIF cut-outs are often smaller.

WebP has two internal codings. Lossless WebP (VP8L) stores every pixel as a 32-bit ARGB value, alpha included, and Google's lossless bitstream specification states that it "stores and restores the pixel values exactly, including the color values for fully transparent pixels". Lossy WebP (VP8) has no alpha of its own, so the container specification adds a separate ALPH chunk holding an 8-bit alpha plane, with an alpha flag in the extended VP8X header. That alpha plane is stored raw or compressed with the lossless coder: a lossy WebP therefore has lossy color and near-lossless transparency, which is why a WebP with a large soft shadow can be surprisingly big.

AVIF stores alpha as a second, monochrome AV1 image inside the same file, marked as an auxiliary alpha item; the AVIF specification requires it to be encoded at the same bit depth as the color image, so an 8-, 10- or 12-bit AVIF gets an 8-, 10- or 12-bit alpha channel. Because the alpha plane is just another AV1 picture, it can be compressed lossily, which WebP cannot do. Jake Archibald's "AVIF has landed" singles this out as part of AVIF's advantage on images with complex transparency. The specification also defines a flag for premultiplied alpha, and mishandling that flag is behind some of the darkened-edge bugs later in this guide.

PNG, for comparison, has two transparency mechanisms: a full alpha channel in RGBA images, and a tRNS chunk that marks one color or a palette entry as transparent. A "transparent PNG" that was saved as an indexed image with tRNS has hard, binary edges; the RGBA kind has soft ones. JPEG has no alpha channel at all, which is the single most common reason a transparent image turns opaque: the moment anything in the chain saves it as a JPEG, the background has to become a color, and that color is usually white or black.

Where transparent WebP and AVIF display correctly in 2026

In every current browser, and in most current apps, both formats show their transparency as intended. Where the alpha channel goes missing, it is nearly always an old decoder, a thumbnail renderer or a platform that converts uploads.

Browsers. Per caniuse.com, WebP is supported by 96.82% of browsers in use as of August 2026; Firefox added it in version 65 (January 2019) and Safari needs version 14 on macOS Big Sur or later. AVIF sits at 95.36%: Chrome 85, Firefox 93 (animated AVIF from Firefox 113), Edge 121, and full support in Safari 16.4, with 16.1 to 16.3 marked partial. Static WebP and AVIF with alpha render correctly in all of them. The known exceptions are animation-specific: WebKit bug 275906, filed in June 2024 and duplicated again in January 2026, reports animated AVIF with transparency playing back with incorrect transparency in Safari, and an Apple Developer Forums thread reproduces the same animated file rendering with a black background in Safari 16.6, 18.3 and 18.5 while Safari 17.5 and Chrome 138 show it correctly.

Operating systems. macOS and iOS decode WebP and AVIF natively in current releases, and Android has decoded AVIF since Android 12. Windows 11 still leans on Microsoft Store extensions for AVIF thumbnails and previews in some configurations, which is why a transparent AVIF can show a plain thumbnail in File Explorer while it renders perfectly in Edge.

Platforms that keep the alpha channel. Discord's engineering team wrote in March 2025 that its media pipeline serves emoji and stickers as WebP and AVIF precisely because both "support variable transparency levels (or alpha channels)", and that more than 95% of its animated emoji now go out as animated WebP. WordPress has accepted WebP uploads since 5.8 and AVIF uploads since 6.5 (February 2024), with a caveat about thumbnails covered below. Wix lists WEBP and AVIF among the formats it accepts for site media.

Platforms that do not. Etsy's help center is unusually direct: "If a file contains transparency, the transparent parts of the image will appear black on Etsy", and transparent PNGs are listed as unsupported. Shopify's CDN has been reported to convert some large PNGs to JPEG, filling the transparency with black. Any marketplace or social network that only stores JPEG will do the same, whatever format you upload. We could not confirm the exact current behavior of eBay, Amazon, Instagram, Facebook or X from their own documentation while researching this guide, so treat every JPEG-only destination as "flatten it yourself, onto the background color the platform wants".

If you sell on marketplaces, the marketplace product image requirements guide covers which platforms want white backgrounds and at what size.

Why your cut-out came back black or white: five causes

A transparent image turns black or white for one of five reasons, and the fix is different for each, so it is worth identifying which one you have before re-exporting anything.

1. The destination re-encoded it as a JPEG

This is the most common cause and the only one you cannot fix with a better file. Marketplaces, social networks and some CMS image pipelines normalize every upload to JPEG for storage and delivery. JPEG cannot represent transparency, so the encoder composites your cut-out onto a solid color. Etsy documents black; many other pipelines default to white. A Shopify community thread from October 2023 describes exactly this: large PNGs automatically converted to progressive JPEG with black backgrounds on roughly one product image in ten.

2. The app that opened it cannot read the alpha channel

The file is fine; the viewer is not. Three well-documented examples: image libraries built on ImageMagick 6 produced AVIFs with black backgrounds instead of transparency (documented in January 2023; the fix was ImageMagick 7), and the same behavior sat as a confirmed, unassigned Ubuntu bug filed in June 2022. WordPress's performance team traced AVIF thumbnails losing their alpha to the server's Imagick version rather than to WordPress itself. On Android, apps using the Glide image loader without its AVIF module rendered transparent AVIFs with black backgrounds on Android 12 and 13 devices (bumptech/glide #5140, May 2023). In each case the same file opened correctly elsewhere.

3. The export never wrote an alpha channel

Some export paths silently drop transparency. LibreOffice added WebP export in 7.4 but its bug tracker carries a confirmed report (bug 160305, March 2024) that WebP export "does not support transparency", which matches the Impress and Draw complaints that a transparent slide element comes out on a white box. Canva accepts WebP uploads but, as of a May 2026 audit of its export menu, offers no WebP or AVIF download at all, so a "transparent WebP" from Canva is a PNG that was renamed or re-encoded somewhere else. Figma's built-in export panel is PNG, JPG, SVG and PDF; WebP and AVIF need a plugin. GIMP exports both formats with alpha, but animated WebP made from layers can composite frames over each other unless you run Filters, Animation, Unoptimize first (GNOME Discourse, October 2023).

4. It is the page, not the file

Two of the three Shopify "transparent product images show a black background" threads we read (April and June 2023) turned out to be theme CSS: the Dawn theme's product-media container had a background color, and the transparent image was doing exactly what it should over it. A one-line CSS change fixed both. Before you re-export anything, open the image on its own; if it is transparent alone and black in the layout, the layout is the problem.

5. Animation and premultiplied alpha edge cases

The rarest cause, and the one with the least satisfying fix. Animated AVIF with transparency renders with a black background in some Safari versions (the WebKit bug above), while static AVIF is fine. Firefox 86 darkened semi-transparent regions of AVIF images on Windows and Linux because alpha premultiplication was applied inconsistently; Bugzilla 1684688 records the fix landing in Firefox 87. If your problem is dark or fringed edges rather than a solid background, and it only shows in one browser, you are here.

Check the file first: does it actually have an alpha channel?

Before changing anything, confirm whether the file you have actually contains transparency, because half of these problems are a file that was flattened before you ever looked at it. Two checks cover both formats.

The visual check. Put the image on a strongly colored page and look at the edges. A one-line HTML file does it:

<body style="background:#e91e63"><img src="cutout.webp"></body>

If the pink shows through around the subject, the file has alpha and the problem is downstream. If you see a white or black box, the file is already flat. Any editor with a checkerboard view (GIMP, Photoshop, Affinity) tells you the same thing.

The command-line check. ImageMagick's identify reports whether every pixel is opaque:

identify -format '%[opaque]' cutout.avif

False means the file contains transparent pixels; True means it is fully opaque, whatever its extension says. The same command works for WebP and PNG. For WebP specifically, ExifTool exposes the container's alpha flag in its WebP_Flags tag, and libwebp's webpinfo lists the chunks (a transparent lossy WebP shows an ALPH chunk; a lossless one carries alpha inside the VP8L bitstream). libavif's avifdec --info does the equivalent chunk-level dump for AVIF.

Once you know the file is transparent, work through the causes above in order: destination, viewer, export, page, then the animation edge cases.

The fix for each cause

Match the fix to the cause; re-exporting a file that was flattened by the destination only wastes the afternoon.

If the cause turns out to be the export, the quickest replacement is a fresh cut-out: Remove Background to WebP writes the alpha channel every time, from the original photo rather than a flattened copy.

PNG, WebP or AVIF for a cut-out?

Google's own figure for lossless WebP is 26% smaller than PNG on average (WebP FAQ), and a lossy WebP with a lossless alpha plane is smaller again. AVIF can go further on images with large soft-edged transparent regions because it compresses the alpha plane lossily, but the gain depends heavily on the image, and we have not benchmarked it on cut-outs, so treat "AVIF is smaller" as usually rather than always true. The trade-off is reach: WebP's 96.82% browser coverage versus AVIF's 95.36% is close, but the long tail of apps, CMS thumbnailers and Windows previews still handles WebP more reliably than AVIF in 2026.

A practical rule: keep a PNG master, publish WebP by default, add AVIF where your stack (a modern CMS, an image CDN, or your own build pipeline) serves it with a fallback, and flatten to JPEG only for the platforms that will do it for you anyway. Our AVIF or WebP for product images answer goes deeper on the size and compatibility trade for e-commerce, and What Is an AVIF File? covers opening AVIF on machines that cannot.

Mochify Workflow: remove a background to transparent WebP or AVIF

Mochify removes a background and writes the result as a transparent WebP or AVIF in one step, on every plan including Free, from any browser. There are three ways in, depending on what you need.

One thing the workflow will not do: make a platform that stores JPEG keep your transparency. If the destination is Etsy, upload the "place it on white" version.

Cheat Sheet: symptom, cause, fix

FAQ