What Is an AVIF File?

AVIF stands for AV1 Image File Format. It was defined by the Alliance for Open Media (AOMedia), a consortium that includes Google, Apple, Mozilla, Microsoft, Netflix, Amazon, and others. The specification was finalized in 2019. The goal was to produce an open, royalty-free still-image format built on top of the AV1 video codec — the same codec those same companies had already built for streaming video.

AV1 itself was created as a royalty-free alternative to HEVC (H.265). Because AV1 carries no per-stream licensing fees, any software developer can decode or encode AVIF files without paying patent royalties to a licensing pool. This open licensing model is part of why browser vendors adopted it quickly: they could ship AVIF support without incurring legal or financial exposure.

The format is not a standalone codec. It is a still-image profile of AV1, meaning it uses only the intra-frame coding tools from AV1 (each image is coded independently, with no reference to other frames) and packages the result in an ISOBMFF container.

AVIF files use the .avif extension. The registered MIME type is image/avif. When a web server sends an AVIF file to a browser, it should include the header Content-Type: image/avif so the browser knows how to decode it. Without the correct MIME type some older proxies and CDN caching layers may serve the file incorrectly.

AVIF image sequences (animated AVIFs) occasionally appear with the .avifs extension, though most tools simply use .avif for both still and animated files. If you receive a file with an unfamiliar image extension and suspect it might be AVIF, the quickest test is to drag it into an up-to-date Chrome or Firefox tab — the browser will display it if it is a valid AVIF regardless of the file extension.

AVIF uses the ISO Base Media File Format (ISOBMFF) as its container. ISOBMFF is a hierarchical “box” structure — the file is divided into typed chunks called boxes, each identified by a four-character code. This is the same container format used by .mp4 video files and by Apple's .heic photos.

Because AVIF and HEIC share the same container family, inspecting the outer box structure of an .avif and a .heic looks superficially similar. The key difference is the codec inside: HEIC stores images encoded with HEVC (H.265), while AVIF stores images encoded with AV1. Two different codecs with very different intellectual property profiles, even though the outer packaging resembles each other. A decoder that only understands HEVC cannot decode an AVIF file, and vice versa.

The ISOBMFF container stores not just pixel data but also color profile information (ICC profiles, CICP color primaries, transfer characteristics), Exif and XMP metadata, and for image sequences, timing information between frames. This means a single .avif file can carry HDR tone-mapping metadata, a wide-gamut color profile, and camera Exif data all in one self-contained package.

When encoding an AVIF, the encoder divides the image into superblocks up to 128×128 pixels in size (compared to JPEG's fixed 8×8 DCT blocks). Larger blocks mean the encoder can describe uniform or smoothly varying regions with far fewer bits because it does not need to repeat coefficients for every tiny tile independently.

Within each superblock, the encoder applies directional intra-prediction: it looks at already-encoded neighboring pixels and predicts what the current block should look like from various angles. If the prediction is accurate, only the small residual error needs to be stored rather than the full block. For smooth gradients and repeated textures this results in a very compact representation.

After prediction, residuals go through a transform (similar in concept to JPEG's DCT but applied at multiple block sizes) and then through entropy coding. AV1 uses a context- adaptive arithmetic coder that achieves very high compression ratios by modeling the probability distribution of each coefficient based on its neighbors. Finally, a loop filter runs over the reconstructed image to remove blocking artifacts at block boundaries, producing smooth edges at compression ratios where JPEG would show visible ringing.

The result is that AVIF achieves better visual quality at a given file size than JPEG not by discarding more detail, but by describing the same detail more efficiently using larger blocks, better prediction, and a more powerful entropy coder.

AVIF has a broader feature set than JPEG. The key capabilities:

• Bit depth: 8-bit, 10-bit, and 12-bit per channel. A 10-bit AVIF provides 1,024 steps per channel versus JPEG's 256, which eliminates visible banding in smooth gradients like skies and skin tones.
• Alpha channel: Full 8-bit or 16-bit transparency. The alpha plane can be stored losslessly even when the color data is compressed, making AVIF a practical replacement for PNG in transparent-image workflows.
• HDR: Supports both PQ (Perceptual Quantizer, used in HDR10) and HLG (Hybrid Log-Gamma, used in broadcast HDR) transfer curves, plus wide color gamuts including Display P3 and BT.2020.
• Animation: The AVIF sequence (AVIS) profile stores multiple frames as individual AV1-coded images in the ISOBMFF container, enabling animated images more compact than animated GIF.
• Film grain synthesis: AV1 includes a film grain synthesis tool that stores a mathematical description of the noise pattern rather than the noise itself. The decoder recreates the grain at display time. This gives photographic images a natural look at very low bitrates without the storage cost of actually encoding each grain pixel.
• Lossless mode: AV1 includes a lossless intra coding mode. In practice this produces files that are often larger and slower to decode than PNG for typical photographic content, so it is rarely used for production images.

A few common misconceptions worth clearing up:

• AVIF is not a video format. Even though it is based on the AV1 video codec, an AVIF file contains only still images (or short image sequences). It does not carry audio, subtitles, or the continuous frame timing that defines a video file. You cannot play an AVIF in a video player in the traditional sense.
• AVIF is not HEIC. HEIC is Apple's format for iPhone camera photos. It uses HEVC (H.265), a different codec developed under a different licensing regime. The two formats share the ISOBMFF container but are otherwise unrelated. See how AVIF compares to other formats.
• AVIF is not WebP. WebP is Google's earlier format, based on the VP8 video codec (a predecessor to AV1). WebP achieves meaningful size savings over JPEG but generally compresses less efficiently than AVIF, particularly at high quality settings.
• AVIF is not lossless by default. Like JPEG, AVIF is a lossy format when used with standard settings. A lossy AVIF at a high quality setting looks visually indistinguishable from lossless, but the pixel values are not bit-for-bit identical to the original.

AVIF support rolled out across major browsers over a two-year window:

Software compiled before roughly 2021 typically has no AVIF support at all. If you receive an AVIF and your viewer shows a blank icon or an error, the most likely cause is a missing decoder in your software — not a corrupted file. See the guide to opening AVIF files on every platform for step-by-step fixes.

JPEG was designed in 1992 for the hardware and mathematical tooling available at the time. Its fixed 8×8 block structure and the DCT transform it uses were state of the art then. Three decades of codec research produced AV1, and the efficiency gains come from specific architectural improvements rather than simply “removing more detail”:

• Larger blocks: AVIF can describe a uniform sky region with a single 128×128 superblock. JPEG must encode the same area as 256 separate 8×8 blocks, each requiring its own set of coefficients.
• Better prediction: Intra-prediction in AV1 uses directional modes, DC prediction, and smooth prediction. JPEG has no intra-prediction; every block is coded from scratch.
• More powerful entropy coding: AV1's context-adaptive arithmetic coder models symbol probabilities more precisely than JPEG's Huffman coding, so the same residual data takes fewer bits to store.
• Loop filtering: The in-loop deblocking and CDEF (Constrained Directional Enhancement Filter) in AV1 clean up block-boundary artifacts at reconstruction time, letting the encoder use more aggressive quantization without visible quality loss.

The net effect is that AVIF can represent the same visual information as JPEG using fewer bits. Encoding the same photograph at a quality level where both look clean to the eye typically produces an AVIF that is meaningfully smaller. The exact ratio depends on the image content, encoder settings, and the quality target, so treat any specific percentage figure with appropriate skepticism — your results will vary by image.

AVIF is the better technical format in most cases, but there are practical situations where converting to an older format is the right move:

• Sharing by email or messaging: Email clients (Outlook, Apple Mail, Gmail) and most messaging apps do not render AVIF inline. The recipient sees a generic file attachment icon instead of the image. Convert to JPG first.
• Social media uploads: Most platforms transcode your uploads to their own internal format anyway, but they often reject AVIF files at the upload step. JPG is accepted everywhere.
• Sending to print labs or design services: Professional print workflows and many stock-photo submission systems require JPEG or TIFF. AVIF is not yet in their accepted-formats lists.
• Preserving transparency for old software: If the destination application does not support AVIF alpha channels but does support PNG, convert to PNG to keep the transparent areas intact.
• Supporting older browsers or embedded webviews: If your audience includes users on iOS 15, Internet Explorer 11, or embedded WebViews in older Android apps, those environments cannot decode AVIF. Use JPG or serve AVIF with a JPG fallback via the HTML <picture> element.

To convert without uploading your file to a remote server, use the AVIF to JPG converter on this site. It runs entirely in your browser using WebAssembly, so your image data never leaves your device. For PNG output with transparency preserved, use the AVIF to PNG converter.

If you prefer working in the terminal, several open-source tools handle AVIF encoding and decoding:

avifenc / avifdec (from the libavif project) are the reference tools:

# Encode a PNG to AVIF at quality 30 (lower = better quality, larger file)
avifenc --min 0 --max 63 -q 30 input.png output.avif

# Decode an AVIF back to PNG
avifdec input.avif output.png

ffmpeg with libavif or dav1d linked can convert between AVIF and common formats:

# Convert AVIF to JPG
ffmpeg -i input.avif -q:v 2 output.jpg

# Convert JPG to AVIF
ffmpeg -i input.jpg -c:v libaom-av1 -crf 30 -still-picture 1 output.avif

ImageMagick (v7 with AVIF support compiled in) also works:

magick input.avif -quality 90 output.jpg

Check that your ffmpeg or ImageMagick build includes AVIF support before running these commands. Run ffmpeg -codecs | grep avif or magick identify -list format | grep AVIF to confirm. If you need a no-install option, the online AVIF converter handles the same conversion without any setup.

Comparing formats in the abstract is less useful than comparing them on real images. The figures below come from encoding the same 24-megapixel sRGB photograph (a street scene with fine detail in foliage and sky gradients) at three quality targets where each format produces results that look clean at 100% zoom on a calibrated display.

A few observations worth pulling out of those numbers:

• ●WebP saves about 30–35% vs JPEG at matching perceptual quality. That gap has been consistent across multiple independent studies since WebP launched in 2010. Google's own 2013 benchmark showed an average 26% saving; more recent tests with updated encoders land around 30%.
• ●AVIF saves about 45–55% vs JPEG and about 20–25% vs WebP. Netflix's 2020 paper introducing AVIF reported a 50% bitrate reduction over JPEG at equivalent SSIM scores across their test corpus. Your images may vary — synthetic textures compress differently than photographs.
• ●The encode-time penalty is the biggest practical trade-off. The libaom reference encoder is extremely slow; SVT-AV1 is 5–10× faster and produces files within a few percent of the same size. For batch workflows, SVT-AV1 at preset 4 or 6 is the practical choice. JPEG encoding at this resolution takes under a second on any modern CPU.
• ●WebP's lossless mode often beats PNG by 25–34% on photographic content, but AVIF's lossless mode is less consistently competitive — PNG or WebP lossless are usually the right pick when lossless is required.

These numbers apply to the photographic test image. Flat-color graphics, illustrations, and images with large uniform regions tend to compress differently: WebP lossless and PNG often outperform AVIF on simple artwork because the entropy in those images is low and AVIF's transform overhead becomes significant relative to the data.

The headline table earlier in this page shows when AVIF landed in major browsers. Knowing the operating-system side of the story matters too, because browsers on older OS versions sometimes cannot render AVIF even when the browser version nominally supports it — the OS-level codec stack can be a dependency.

The important practical conclusion from this table: as of late 2026, global browser support for AVIF sits above 93% according to caniuse.com data. The remaining gap is mostly older iOS devices that cannot upgrade past iOS 15 and a shrinking tail of Chromium-based browsers on very old Android versions. For a new web project launched today, AVIF is safe as the primary format with a WebP or JPEG fallback served via<picture> element source ordering.

AVIF is not universally the right choice. Understanding the cases where it actively hurts — rather than just failing to help — saves time and avoids surprises in production.

• →

  You need fast server-side batch encoding. The libaom encoder at quality-competitive settings (crf 30, speed 4) takes 40–120 seconds per megapixel on a modern CPU. If you are encoding thousands of product images on the fly at upload time, AVIF will create a severe backlog. WebP encodes in 2–5 seconds for the same image. SVT-AV1 narrows the gap to roughly 5–10 seconds, but that is still 5–10× slower than WebP. For high-volume pipelines, pre-encode asynchronously or use a CDN-side image transformation service rather than encoding inline during the HTTP request.

• →

  The image will be embedded in a PDF or printed document. PDF readers, word processors, and desktop publishing tools almost universally rely on JPEG or PNG as their embedded raster format. An AVIF dropped into a Word document or InDesign layout will either fail to embed, display as a broken placeholder, or get silently rasterized to a lower-quality PNG at the PDF export stage. Convert to JPEG before embedding in any print workflow.

• →

  The recipient's environment is unknown and you cannot serve a fallback. If you are sending a single image file via email, chat, or a shared drive — not via a web page where you control the HTML — you cannot guarantee the recipient's viewer supports AVIF. A macOS 12 user, an Outlook user on Windows 10 without the AV1 codec installed, or anyone on iOS 15 will see a blank or error. JPEG or PNG are the safe choices for “send a file and forget it” scenarios.

• →

  The image is a lossless screenshot or UI mockup. AVIF's lossless mode exists but is rarely competitive with PNG or WebP lossless on screen-capture content. Flat UI colors, crisp text, and hard pixel edges are exactly the content profile where AVIF's transform overhead is least justified. PNG typically beats AVIF lossless on these images by 15–30%, and the encode time for PNG is near-instant.

• →

  You need the file to decode quickly on low-end hardware. AVIF decoding is more CPU-intensive than JPEG or WebP decoding because the AV1 bitstream requires more complex inverse transforms. On a current flagship smartphone this is invisible, but on a budget Android device from 2019–2021 with no hardware AV1 decoder, a large AVIF can take 300–600 ms to decode vs under 100 ms for an equivalent JPEG. If your audience is heavily on low-end devices, measure decode latency on representative hardware before committing to AVIF at large sizes.

• →

  The image is already heavily compressed. Re-encoding a JPEG that was saved at quality 60 to AVIF will not recover the detail lost in the original JPEG compression — it will only compress the artifacts. The resulting AVIF file will be smaller but may look worse than a clean JPEG at the same size because AVIF's encoder is now trying to efficiently represent JPEG blocking artifacts rather than the original signal. If the source file has a quality history you cannot verify, decode to an uncompressed intermediary (PNG or TIFF) before re-encoding to AVIF.

The short rule: AVIF wins on web delivery of photographs and rich graphics where you control the serving environment and can provide fallbacks. It loses or is neutral in offline, print, document-embedding, and lossless-screenshot contexts.