How Browsers Handle AVIF Files Missing avif Brand

When an AVIF image omits the essential avif brand from its ISO Base Media File Format (ISOBMFF) header, web browsers encounter a structural validation failure during image parsing. This article examines how major rendering engines handle this parsing discrepancy, the resulting decode errors, UI fallback representations, and why standard HTML fallback techniques often fail to recover from this specific container-level omission.

The Role of the ftyp Box in AVIF Validation

AVIF files rely on an ftyp (file type) box situated at the very beginning of the file. This box designates a major_brand alongside a list of compatible_brands. According to the AVIF specification developed by the Alliance for Open Media (AOMedia), conforming files must list avif (or avis for image sequences) as either the major brand or within the compatible brands array.

Standard browser image decoders—such as Chromium's Blink (using libavif), Mozilla's Gecko, and Apple's WebKit—interrogate this box immediately after receiving initial bytes. If the avif brand is present in compatible_brands, the browser generally decodes the image even if the major_brand is generic (such as mif1). However, if avif is absent from both fields, the decoder treats the file as an unsupported or corrupt media type.

Decoder Rejection and DOM Error States

When an image tag (<img src="graphic.avif">) references a file missing the avif identifier, the browser will not attempt to interpret the underlying AV1 bitstream, even if the payload is completely intact.

The browser handles this failure through the following chain of actions:

1. Decoder Abort: The image-decoding pipeline reads the container headers, fails the brand validation check, and aborts processing.
2. DOM Event Dispatch: The <img> element fires an error event instead of a load event.
3. UI Replacement: The browser displays its standard broken-image placeholder along with any provided alt text. The layout engine renders the element according to fallback styling rules (or collapses it if no dimensions are specified).

The <picture> Element Limitation

Web developers often rely on the <picture> element to offer progressive enhancement:

<picture>
  <source srcset="image.avif" type="image/avif">
  <img src="fallback.jpg" alt="Description">
</picture>

When an AVIF file lacks the avif brand, the <picture> element fails to serve as a safety net. HTML source selection occurs based on the type attribute and the HTTP Content-Type header (typically image/avif). Because the browser supports the declared MIME type, it selects the <source> tag, sends the network request, and commits to that source.

Once the file arrives and fails decoding due to the missing brand, browser rendering engines do not backtrack down the list of <source> elements. The entire picture element enters a broken state, leaving the user with an empty or broken image frame rather than the designated JPEG or WebP fallback.

Direct Navigation and Standalone Viewing

If a user navigates directly to the malformed AVIF file URL:

• Chromium-based browsers (Chrome, Edge): The browser typically displays an internal error frame indicating that the image cannot be displayed because it contains errors.
• Firefox: Gecko renders a textual error page stating that the image cannot be shown because it contains errors.
• Safari: WebKit may attempt to evaluate other container brands (such as mif1 or miaf). If no supported media brand is found, Safari triggers a file download rather than attempting inline rendering.

Impact of Partial Omission

If a file lists a generic container format like mif1 as the major_brand while properly retaining avif within the compatible_brands list, modern browsers generally decode the file without issue. The critical failure occurs exclusively when the avif token is entirely stripped from both the major brand and the compatibility table, completely decoupling the file container from the browser's AV1 image pipeline.