AVIF ISOBMFF Minimum Container Overhead

The AV1 Image File Format (AVIF) encapsulates compressed image data inside the ISO Base Media File Format (ISOBMFF) container. While AVIF provides superior compression efficiency compared to older formats, the ISOBMFF architecture imposes a fixed structural cost. This article breaks down the minimum byte overhead required by the ISOBMFF structure in a standalone AVIF file, examines the mandatory boxes responsible for this footprint, and highlights the performance implications for ultra-small web assets.

The Minimum Overhead: 200 to 250 Bytes

In a fully compliant, minimally structured single-frame AVIF file, the ISOBMFF container introduces approximately 200 to 250 bytes of fixed overhead before accounting for any actual AV1 image bitstream data. Standard production encoders (such as libavif or cavif) typically produce container overhead closer to 250 to 350 bytes due to optional metadata, padding, and explicit color profile tags.

Breakdown of Required ISOBMFF Boxes

An AVIF image relies on the HEIF specification, which utilizes specific ISOBMFF structures called "boxes" (or atoms). Each box consists of a 4-byte size integer, a 4-byte four-character code (FourCC), and optional version/flags fields.

To construct the smallest possible valid AVIF file, the following boxes must be present:

• ftyp (File Type Box) — ~24 to 32 bytes: Identifies the file specification. It contains the major brand (avif), a minor version, and a list of compatible brands (such as avif, mif1, and miaf).
• meta (Meta Box) — Enclosing container: A container box marked as a FullBox (header + 4 bytes for version and flags) that encapsulates item management metadata. Inside the meta box:
  • hdlr (Handler Box) — ~32 bytes: Declares the metadata handler type (typically pict for picture items).
  • pitm (Primary Item Box) — ~12 to 14 bytes: Specifies the ID of the primary image item.
  • iloc (Item Location Box) — ~24 to 40 bytes: Defines the offset and length of the compressed image payload inside the file.
  • iinf and infe (Item Info Box) — ~36 to 48 bytes: Lists and describes the image item (setting the item type to av01).
  • iprp (Item Properties Box) — ~80 to 120 bytes: Aggregates item properties within an ipco (Item Property Container) and associates them via an ipma (Item Property Association) box. Mandatory sub-boxes include:
    • ispe (Image Spatial Extents): Defines pixel width and height (~20 bytes).
    • av1C (AV1 Codec Configuration): Contains sequence header information required by decoders (~16 to 24 bytes).
    • pixi (Pixel Information): Declares bit depth and channel count (~16 bytes).
• mdat (Media Data Box) — 8 bytes (header only): Wraps the raw AV1 Open Bitstream Unit (OBU) payload. The box header itself requires 8 bytes (4 bytes for length, 4 bytes for the mdat tag).

Practical Implications for Small Images

Because the ISOBMFF structure requires over 200 bytes of mandatory metadata, AVIF exhibits diminishing returns for micro-assets such as 16x16 favicons, tiny icons, and low-quality image placeholders (LQIP).

For example, if an AV1-encoded 16x16 image frame consumes only 60 bytes of raw image data, the final .avif file will still measure around 280 to 320 bytes due to the container requirements. In such scenarios, alternative formats with lighter headers (such as WebP, which introduces an overhead of roughly 30 to 40 bytes via RIFF) can yield smaller overall file sizes despite having less efficient compression algorithms.