AVIF Transparency and Alpha Channels

Every pixel in a digital image has a color value and, optionally, an opacity value. That opacity value is called the alpha channel. A fully opaque pixel has an alpha of 255 (in 8-bit terms); a fully transparent pixel has an alpha of 0; anything in between is semi-transparent. Gradients, soft drop shadows, feathered selection edges, and smooth anti-aliasing all rely on those intermediate alpha values to blend cleanly against whatever background sits beneath them.

AVIF encodes the alpha channel as a completely independent plane, separate from the color data. The color planes (typically Y for luma, Cb and Cr for chroma) are encoded with one set of compression parameters, and the alpha plane is encoded with its own parameters, often losslessly. When the decoder reconstructs the image, it reads both planes and combines them. This architecture means semi-transparent pixels survive at full precision — the soft edge of a logo rendered over a dark background will look just as smooth after decoding as it did before encoding, provided the encoder preserved the alpha plane.

The underlying container is ISOBMFF (the same box structure used by MP4 files), and the alpha plane is stored as an auxiliary image track. Encoders like libavif let you choose between lossy and lossless alpha independently of the color quality setting, which is useful when you want aggressive color compression but pixel-perfect transparency edges.

All four major web formats handle transparency differently, and the differences have real consequences when you are picking a format for logos, UI elements, or product cutouts.

JPEG was standardized in 1992, when storing opacity data in a photographic image format was not a design goal. It encodes 24-bit RGB data only; there is no fourth channel and no mechanism to add one. Standard JPEG will never support transparency. JPEG XL is a different, newer format that does support alpha, but it has no relation to the classic JPEG you encounter every day.

PNG, released in 1996, has always supported full RGBA with lossless compression. It remains the most universally compatible transparent image format. AVIF's advantage over PNG is file size: because AVIF uses AV1-based compression rather than DEFLATE, an AVIF with lossless alpha and lossy color can be substantially smaller than an equivalent PNG, especially for photographic content with soft transparent edges.

The most common way transparency is destroyed during conversion is compositing. When a decoder reads an AVIF that contains an alpha plane, it has two choices: it can pass the RGBA data through to the next step, or it can flatten the image against a background color and produce RGB-only data. Many tools — particularly older desktop converters and poorly configured pipelines — choose the second option automatically, without warning you.

The result is often called a “white halo” or “white box.” If you convert a logo with a transparent background to PNG using a tool that composites against white first, the output PNG will have a solid white background. The file format is correct (PNG supports transparency), but the transparency data was never written because the compositing step already discarded it. The image looks fine on a white page but develops an ugly white border the moment you place it on any other background.

Converting AVIF directly to JPEG is a guaranteed transparency loss, because JPEG cannot store alpha at all. Every converter must composite the transparent areas against some color before writing the JPEG. White is the most common default. If your transparent areas were meant to be invisible against a dark background, you will get white patches instead. This is not a bug in any particular tool; it is the mathematical reality of converting from a format with four channels to one with three.

If you need the image in JPEG format and it originally had transparency, the correct workflow is: decide on a background color that matches the intended display context, composite deliberately during conversion rather than letting the converter pick for you, then encode to JPEG. Our AVIF to JPG converter composites against white by default, which is correct for most web and print uses. For dark-background contexts, convert to PNG instead and keep the alpha intact.

PNG is the right output format when you need to preserve alpha. The goal is to find a conversion path that reads the AVIF alpha plane and writes it directly to the PNG alpha channel without any compositing step in between.

In a browser you can use our AVIF to PNG converter, which decodes the AVIF using the browser's native AVIF decoder, draws the RGBA data to a canvas configured with an alpha channel, and encodes the canvas to PNG via the Canvas API. Nothing is composited; the alpha values are passed through intact. The output file will have a transparent background that renders correctly on any background color.

On the command line, ffmpeg can do the same conversion while preserving transparency:

ffmpeg -i input.avif -pix_fmt rgba output.png

The key flag is -pix_fmt rgba, which tells ffmpeg to keep a four-channel pixel format rather than dropping the alpha. Without it, some ffmpeg builds default to rgb24 (three channels) and silently discard the alpha plane. ImageMagick also handles transparent AVIF to PNG correctly in recent versions:

magick input.avif -background none output.png

The -background none flag tells ImageMagick not to flatten the image before encoding. Omitting it on some versions will cause compositing against the default background color, which is white unless you have changed your ImageMagick policy.

After converting a transparent image, you need to confirm the alpha channel is actually present in the output file and not just a transparent-looking image composited onto white. There are two reliable ways to check.

The quickest method is the dark background test. Open the converted image in any tool that lets you control the background color of the canvas area — a browser works perfectly because you can use CSS. Set the page or element background to a dark color like black or navy blue, then display the image over it. If the edges look natural and blend smoothly, the alpha is intact. If you see a white rectangle or halo around the subject, the alpha was composited during conversion and the output file is not transparent at all.

The second method is the checkerboard test, which is standard in every image editor. Open the output file in Photoshop, GIMP, Figma, or any tool that displays a grey and white checkerboard pattern behind transparent areas. If you see the checkerboard where you expect transparency, the alpha channel is present and correct. If you see a flat white fill instead of the checkerboard, the transparency was lost during conversion.

• Place the image over a dark colored div in a browser with background-color: #1e1e1e and inspect the edges visually.
• Open in GIMP or Photoshop and check whether the checkerboard pattern appears in the transparent regions.
• Run identify -verbose output.png | grep Alpha with ImageMagick to confirm an alpha channel is listed in the image attributes.
• In a browser devtools console, draw the image to a canvas and read a pixel you expect to be transparent: a fully transparent pixel will have an alpha value of 0 in getImageData.

Transparent image formats are essential for a specific category of web assets. These are the cases where choosing the right format (and the right conversion path) matters most.

Logos and brand marks need to sit on many different backgrounds without carrying a white box. A company logo saved with transparency can be placed on headers, footers, hero sections, dark-mode pages, and printed collateral without re-exporting for each background color. PNG has been the standard format for this use case for decades. AVIF with lossless alpha can replace PNG here when file size matters and browser support is acceptable, with a PNG fallback via the HTML <picture> element for older browsers.

UI icons and illustrations with fine detail and smooth anti-aliasing need accurate semi-transparent pixels. A magnifying glass icon, a close button, or a custom checkbox rendered with anti-aliased edges has dozens of partially transparent pixels along its boundary. These must survive format conversion intact; otherwise the icon will develop a fringe of the background color it was originally designed against.

Social card images and sticker-style graphics are often composited programmatically: a server reads a foreground element with transparency and places it over a generated background. If the foreground loses its alpha during storage or retrieval, the compositing pipeline breaks. Storing the foreground as AVIF with an intact alpha plane and reading it back with a library that preserves the alpha is the correct approach for these automated workflows.

Product photography cutouts, where a product is photographed against a plain background and then masked to transparency, benefit from AVIF's ability to compress the color data aggressively while keeping the soft edges of the mask lossless. This reduces the file size of the product image on the listing page without introducing artifacts around the subject.

You can learn more about how AVIF compares to PNG in other respects on the AVIF vs JPG comparison page, or convert a transparent AVIF right now on the AVIF to JPG home page.

For many common image types, the presence or absence of transparency support is entirely irrelevant, and choosing a format based on alpha capability would be overthinking it.

Full-frame photographs — landscape shots, portraits, food photography, real-estate interiors — fill the entire canvas with opaque pixels. There is no transparent region to preserve. For these images, JPEG and AVIF both work fine from a transparency standpoint, and the choice between them should be based on file size, quality, and compatibility rather than alpha support.

Hero images and banner graphics that are designed for a specific background color and will never be placed anywhere else can be safely saved without an alpha channel. If you know the image will always sit on a white page, composite it against white and save as JPEG — you get a smaller file with no compatibility concerns. The transparency capability of AVIF or PNG only helps when the image needs to adapt to multiple backgrounds.

Print workflows are another area where alpha is rarely relevant. Most print pipelines work with CMYK or RGB without transparency, and print drivers do not render transparent image layers the way a browser does. If you are preparing images for a print-on-demand service, a magazine layout, or physical signage, the destination format is almost always an opaque JPEG, TIFF, or PDF. The effort of preserving alpha through a print pipeline is usually wasted.

Office documents present a similar reality. When you insert an image into Word, PowerPoint, or Google Slides, those applications can handle PNG transparency reasonably well, but they often struggle with AVIF. The practical advice here is to convert the transparent image to PNG before inserting it into an office document, regardless of the source format. Most office software reads PNG alpha correctly and will render the transparent regions as expected against the slide or page background.

When a browser displays an AVIF image with an alpha channel inside an <img> tag, it decodes the color planes and the alpha plane independently, then composites the result against the CSS background of the element or the page. This is the same process used for PNG and WebP: the browser handles the compositing step, not the image file itself.

In practice this means a transparent AVIF logo displayed on a dark-mode page will blend correctly without any changes to the image file — the browser composites against the dark background automatically. Chrome has supported AVIF (including alpha-channel AVIF) since Chrome 85. Firefox added AVIF support in Firefox 93. Safari added it in Safari 16.1. If you need to serve transparent AVIF images to older Safari users (iOS 15 or earlier, macOS Monterey and earlier), you should include a PNG fallback using the HTML <picture> element:

<picture>
  <source srcset="logo.avif" type="image/avif" />
  <img src="logo.png" alt="Company logo" width="200" height="80" />
</picture>

Browsers that understand AVIF will use the <source> element and display the smaller AVIF file. Browsers that do not support AVIF will fall back to the PNG. Both files should have their alpha channels intact. This pattern lets you serve smaller files to modern browsers without breaking the experience for anyone on older software.

You can open and inspect any AVIF file including ones with transparency using the AVIF viewer before converting, so you can confirm the alpha channel is present in the source file before committing to a conversion path.

Standard PNG and WebP alpha channels store 8 bits of opacity per pixel, giving 256 discrete levels from fully transparent (0) to fully opaque (255). AVIF inherits AV1's support for 10-bit and 12-bit depth, which means its alpha plane can carry 1,024 or 4,096 distinct opacity levels. The practical difference shows up in large, smooth gradients: an 8-bit alpha gradient that fades from 100% opacity to 0% over 2,000 pixels has only 256 steps, which can produce a faint banding pattern on high-contrast backgrounds. A 10-bit alpha gradient has 1,024 steps across the same distance, and banding disappears entirely.

In practice, most web images never need 10-bit alpha. Icons, logos, and product cutouts all have sharp or moderately soft edges that an 8-bit alpha encodes without visible artifacts. The use cases that benefit most are large-format UI elements with very gradual transparency gradients — think a full-viewport frosted-glass overlay that fades in over 400 pixels, or a high-resolution poster with a fog-effect vignette. If you are encoding images like this with libavif on the command line, set --depth 10 on the alpha plane to keep the gradient data at full precision.

One important compatibility note: Safari on iOS 16 and macOS Ventura correctly decodes AVIF at 10-bit depth, but some canvas-based JavaScript decoders downscale alpha to 8 bits when reading image data. If you read a 10-bit AVIF with getImageData on a standard 2D canvas, you will receive 8-bit per channel values regardless of the source precision, because the HTML Canvas API itself uses 8-bit color internally. Only WebGL or the experimental ImageBitmap pipeline with a float-32 framebuffer preserves more than 8 bits of alpha in JavaScript.

When you run a batch conversion of hundreds of AVIF files, you will almost certainly encounter a mix of results: most files convert correctly, a handful come out with white backgrounds, and occasionally one produces a completely black or grey image instead of preserving the expected transparency. Understanding why individual files in the same batch behave differently saves hours of investigation.

The most common cause of inconsistent batch results is that not all of your source AVIF files actually contain an alpha plane. A file that was created by encoding a PNG with a transparent background will have an alpha plane. A file that was created by encoding a JPEG or an opaque photo will not. When your conversion command uses -pix_fmt rgba or the equivalent, it works correctly for both cases: files with alpha come through intact, and files without alpha get a fully opaque alpha channel added automatically. The problem arises with tools that only add the alpha flag when they detect it in the source: if detection fails on a particular file, the tool falls back to an RGB output and composites the alpha plane against white before discarding it.

A reliable triage workflow for batch output looks like this:

• Run identify -format "%f %[channels]\n" *.png with ImageMagick on the output directory. Files without an alpha channel will report srgb instead of srgba; these are the failures.
• For each failure, check the source AVIF: run avifinfo input.avif (if available) or open it in a browser. If the source genuinely has no alpha plane, there is nothing to preserve and the result is correct.
• If the source has an alpha plane but the output does not, the tool composited during conversion. Re-run with an explicit alpha-preservation flag: ffmpeg -i input.avif -pix_fmt rgba output.png or magick input.avif -background none output.png.
• For very large batches, a two-pass strategy is efficient: first extract all files that report an alpha plane in the source, convert those with alpha-safe flags, then convert the remainder with standard flags. The two passes run independently and both succeed.

A black or near-black result (rather than a white one) usually means the converter pre-multiplied the color values by the alpha before discarding the alpha channel. Pre-multiplied alpha is a technical optimization used inside some renderers where each RGB value is already multiplied by the corresponding alpha value. If a converter reads pre-multiplied AVIF data and writes it to a PNG without un-multiplying first, all near-transparent pixels will appear nearly black in the output. The fix is to force the converter to un-multiply: in ImageMagick this is -alpha on combined with -background none; in ffmpeg it requires the unpremultiply filter applied before the PNG encode step.

When you place a transparent image on a web page, two separate compositing operations occur. First, the browser decodes the image and obtains RGBA pixel data. Second, CSS compositing rules determine how those pixels blend with the elements behind them. The CSS mix-blend-mode property controls the second step, and it interacts with AVIF alpha in ways that are not always obvious.

With the default mix-blend-mode: normal, the browser performs a standard alpha compositing: each pixel in the image covers the background proportionally to its alpha value. A pixel with alpha 128 (50% opaque) will show exactly half the image color and half the background color. This is the behavior you get automatically with any transparent AVIF in an <img> tag; no special CSS is required.

mix-blend-mode: multiply is commonly used for watermark-style overlays and texture effects. When applied to a transparent AVIF image, the blend affects only the opaque and semi-transparent pixels, not the fully transparent ones. A logo on a transparent background displayed with multiply blending will appear to have its colors multiplied against the background within the opaque area, while the transparent regions remain invisible. This works correctly in all modern browsers for AVIF, WebP, and PNG transparencies.

A common pitfall is mix-blend-mode: screen on a logo that was designed to appear on a dark background. If the logo has a white-colored design on a transparent field, screen blending against a white page background makes the entire logo disappear: white screened against white produces white. In this case the solution is not to remove transparency from the AVIF, but to use the right blend mode for the context, or to place the image inside a container with a dark background color. The AVIF alpha itself is correct; the issue is a CSS configuration mismatch.

One specific case where AVIF alpha interacts differently from PNG: if you use isolation: isolate on a parent container alongside mix-blend-mode on child images, the browser creates a new stacking context and composites AVIF and PNG children identically. Without isolation: isolate, blend modes on AVIF images can sometimes bleed through multiple parent layers in Chromium-based browsers, a behavior that PNG images in the same position do not reproduce. Wrapping your blended AVIF in a <div style="isolation: isolate"> container resolves the inconsistency across both Chromium and Firefox.