AVIF Browser Support: Version Timeline and Fallbacks

AVIF support rolled out across browsers over roughly two years. Chrome 85 shipped in August 2020 and was the first major browser to decode AVIF images natively, covering both desktop and Android. Because Microsoft Edge switched to the Chromium engine, it picked up AVIF support shortly after in Edge 90 (April 2021) without any separate engineering work.

Firefox took a more deliberate approach. The team wanted to ensure both still images and AVIF sequences (animated AVIF) worked correctly before shipping, so Firefox 93 in October 2021 arrived with full support rather than a staged rollout. Firefox's implementation uses the dav1d AV1 decoder, which is the same open-source decoder embedded in VLC and several other media players.

Safari was the last of the major three to land AVIF. Apple added support in Safari 16.1, released in October 2022 alongside macOS Ventura and iOS 16.1. This milestone closed the last significant gap among evergreen browsers, since Safari on iPhones and iPads had previously been the blocker for sites that wanted to serve AVIF without a fallback. Samsung Internet, which runs on Chromium, gained AVIF support in its v14 release (February 2021), making it available on Galaxy devices well before Safari arrived.

One important nuance: even within a supported browser version, AVIF decoding depends on the device having enough CPU power for AV1 decoding. On very low-end hardware, a browser that “supports” AVIF may decode large images noticeably slower than it would decode an equivalent JPEG. This is a performance consideration, not a compatibility gap, but it matters for audiences on entry-level Android phones.

Despite broad coverage in current browsers, there are real categories of software and device where AVIF will not display correctly. Knowing these gaps is what determines whether a fallback is optional or mandatory for your use case.

• Internet Explorer (all versions): IE has no AV1 decoder and Microsoft officially retired it in June 2022. Any AVIF image served to IE will either show as a broken image icon or trigger a file download. Sending AVIF to an IE user without a fallback breaks the page.
• Safari on iOS 15 and earlier: iPhones and iPads that cannot upgrade past iOS 15 — specifically iPhone 6s, iPhone 7, and first- and second-generation SE — will not display AVIF in Safari. These devices are still in active use.
• Safari on macOS Monterey and earlier: Macs running macOS 12 (Monterey) or older lack the AVIF-capable Safari 16.1. The AVIF image renders as a broken placeholder in Safari on those systems.
• App-embedded WebViews on older OS versions: When users open a link inside a messaging app like WeChat or a news app, the page renders in an in-app WebView rather than the system browser. On Android, that WebView typically tracks Chrome's engine, but on older Android versions it may lag. On iOS, every in-app browser uses WebKit — so the iOS 15 gap applies here too.
• Smart TVs, set-top boxes, and kiosks: These devices run customized browser engines that are often years behind the mainstream release cycle. Most do not support AVIF and are unlikely to add it through firmware updates.
• Image viewers and office software: Software that can display images but is not a browser — Windows Photo Viewer, older versions of Microsoft Word, PowerPoint, Outlook — generally does not decode AVIF. This is separate from browser support and matters when you share AVIF files as attachments rather than web assets.

Browser support for AVIF means a browser can decode and render an AVIF inside a web page. It does not mean the operating system's file manager can generate a thumbnail, and it does not mean every desktop application can open the file. These are three separate capabilities that a device may have in any combination.

Chrome on a Windows 10 machine will display an AVIF in a web page perfectly. But if you save that same file to your desktop and double-click it, Windows Photo Viewer will show an error unless you have installed the free AV1 Video Extension from the Microsoft Store. Similarly, the Windows File Explorer will not show a thumbnail preview for AVIF files on Windows 10 without that codec — even though Chrome on the same machine handles AVIF fine.

macOS Ventura and later handle this more cleanly: the system-level Image I/O framework gained AVIF support, so Preview, Quick Look in Finder, and Safari all decode AVIF through the same engine. On macOS Monterey and earlier, that system-level support is absent, so even if you installed a third-party browser that supports AVIF, the Finder and Preview still cannot render it.

The practical takeaway is that browser support is the minimum bar, not the complete picture. If you are building a web page, browser support is what matters. If you are sharing AVIF files as attachments or using them in documents, the recipient's OS and app ecosystem is the constraint — and converting AVIF to JPG before sending is the safest path when you cannot control what the recipient has installed.

Because AVIF support is not universal, production web pages should always include a fallback for browsers that cannot decode it. There are three standard approaches, each with different tradeoffs.

Option 1: HTML picture element with source type (recommended). This is the most widely used technique and requires no server configuration. The browser reads the source elements in order and picks the first format it can decode. Older browsers that do not understand the picture element fall back to the img tag.

<picture>
  <source srcset="/photo.avif" type="image/avif" />
  <source srcset="/photo.webp" type="image/webp" />
  <img src="/photo.jpg" alt="Description" width="800" height="600" />
</picture>

A browser that supports AVIF downloads only the AVIF and ignores the WebP and JPEG sources. A browser that supports WebP but not AVIF downloads only the WebP. Internet Explorer and other legacy browsers fall through to the img tag and download the JPEG. No JavaScript is required and no server logic is involved.

Option 2: Server-side content negotiation via Accept header. When the browser requests an image, it includes an Accept header listing the formats it supports. Chrome sends Accept: image/avif,image/webp,*/*. Safari 16+ sends the same. Firefox includes image/avif in its Accept header from version 93 onward. A server or CDN can inspect this header and serve the most efficient format automatically, without changing any HTML. This approach works well on CDNs like Cloudflare Images and AWS CloudFront with Lambda@Edge, and keeps your HTML clean. The tradeoff is that it requires server-side configuration rather than a pure HTML solution.

Option 3: JavaScript capability detection. A small script can probe whether the current browser can decode AVIF by attempting to decode a minimal valid AVIF blob using createImageBitmap. If decoding succeeds, the script adds a class to the HTML element (or sets a cookie) that your CSS or lazy-loading code can use to select the AVIF source; if it fails, the JPG source is used instead. This approach is more fragile than the picture element — it introduces a small timing dependency and requires JavaScript to be running — so it is generally only justified when you need fine-grained control beyond what the picture element provides, such as dynamically assembled image URLs in a JavaScript-heavy application.

When you navigate directly to a URL that points to an AVIF file — for example by dragging it into a browser tab, opening it with File → Open, or following a direct link — the browser attempts to render it as a standalone image in the tab. In Chrome, Firefox, and Safari 16.1+, the image displays correctly just as a JPEG or PNG would.

In browsers that do not support AVIF, the behavior varies. Some browsers display a broken image placeholder. Others prompt the user to download the file because they do not recognize the MIME type image/avif as something they can display. In neither case is the file itself corrupted — the browser simply lacks the decoder. Opening the same URL in a modern Chromium-based browser will show the image immediately.

If you receive an AVIF file and cannot open it with your current browser or OS tools, the fastest resolution is to use a browser-based converter. The AVIF to JPG converter on this site decodes AVIF entirely in your browser using WebAssembly — no file upload required — and produces a JPEG you can open anywhere. You can also use the AVIF viewer to preview the image without converting it, as long as your browser supports AVIF.

AVIF files are smaller than JPEGs partly because AV1 is a much more computationally intensive codec than JPEG's DCT algorithm. Decoding an AV1-encoded image requires significantly more CPU work than decoding an equivalent JPEG. On modern desktop CPUs and flagship phones, this difference is imperceptible — decoding happens in milliseconds either way. On low-end Android devices with slower cores and no hardware AV1 decoder, loading a large AVIF (say, a 4000 × 3000 px hero image) can take long enough to produce a visible delay before the image appears.

Hardware AV1 decoding has been appearing in SoCs since around 2021 (present in Apple A15 and later, and in mid-range Snapdragon 8 Gen 1 and later). Devices with hardware decode support show no meaningful performance difference between AVIF and JPEG. Devices without hardware decode — older phones, budget tablets — do the work in software, which consumes more battery and runs slower on already-constrained hardware.

The practical implication: if your audience skews toward low-end Android hardware, measure real decode latency before committing to AVIF as your primary format. A smaller file download might be offset by a longer decode delay, resulting in a worse Largest Contentful Paint score rather than a better one. Serving WebP to those users and AVIF to modern browsers is a reasonable middle path — the picture element handles this automatically without any JavaScript.

For desktop audiences and modern phone users, the performance concern is minimal. The bandwidth savings from AVIF — typically substantial compared to JPEG at equivalent visual quality — translate directly to faster page loads on all connection types, and the decode cost is small relative to the network savings.

Browser support does not transfer to email clients or office applications. Outlook, Apple Mail, and Gmail's web interface all render email HTML in their own stripped-down engines, none of which support AVIF inline images as of now. An AVIF embedded in an email will show as a broken image in virtually every email client. The same applies to images pasted into Word documents, Google Slides, or PowerPoint — those applications use their own image decoders, and AVIF is not yet on their supported list.

Print workflows have a similar gap. PDF generators, print management software, and RIP (raster image processor) systems used in professional printing almost universally expect JPEG, TIFF, or PNG. Sending AVIF to a print lab or into a desktop publishing workflow is likely to produce errors. The safe practice is to keep AVIF on the web where browser support exists, and convert to JPEG or PNG for anything leaving the browser context — email attachments, document embedding, print submission, or sharing via messaging apps.

A simple rule covers most situations: use AVIF for images on your own website, where you control the serving environment and can add a picture fallback; use JPEG for everything else. If you regularly receive AVIF files from cameras or design tools and need to forward them to people who may not have compatible software, converting them through a browser-based tool before sending eliminates the compatibility risk entirely.

Before serving AVIF on a site or sharing AVIF files, running through a short checklist prevents the most common compatibility problems.

• Website images: Always wrap AVIF sources in a <picture> element with a JPEG or PNG <img> fallback. This single change eliminates the risk of broken images on older Safari, IE, and embedded WebViews.
• Email and documents: Convert to JPEG or PNG before attaching or embedding. Use the AVIF to JPG tool for a fast in-browser conversion with no upload required.
• Print and PDF: Export from your source application as TIFF or PNG at full resolution, or use JPEG at quality 95 or higher. Do not pass AVIF files to print workflows unless the specific software explicitly lists AVIF support.
• Sharing with unknown recipients: When you do not know what device or software the other person has, JPEG is the universal safe choice. Converting takes seconds and removes any compatibility uncertainty.
• Low-end mobile audiences: Consider serving WebP as the primary format with AVIF as the progressive enhancement for modern hardware. Measure Largest Contentful Paint on representative low-end devices before committing to AVIF as the sole modern format.
• In-app WebView content: Treat in-app browser environments as if they may be running iOS 15 or an older Android WebView. A JPEG fallback in the picture element costs nothing and prevents blank images for users on older OS versions.

If you need to check browser support interactively before implementing, opening an AVIF to JPG online converter in the target browser is a quick way to confirm whether that browser can decode AVIF at all — if the converter can read and display your file, the browser has a working AVIF decoder.

Rendering speed varies more than most developers expect. On a 2022 M2 MacBook Air, Chrome 120 decodes a 4 MP (3840×2160) AVIF still image in under 40 ms using the hardware-accelerated AV1 path in macOS 13+. The same file on a 2017 Core i5 laptop running Chrome 120 takes around 180 ms — still imperceptible for a single hero image, but noticeable if you are lazy-loading a grid of 20+ thumbnails simultaneously.

iOS 16.1 introduced hardware AV1 decoding on A17 Pro chips (iPhone 15 Pro and later). Older iPhones with iOS 16.1 — such as the iPhone 12 or 13 — support AVIF but fall back to software decoding. In practice, decoding a 1 MP AVIF thumbnail takes about 25 ms in hardware versus 90–120 ms in software on those devices. If your audience skews toward older mid-range Android phones (Snapdragon 600 or 700 series, pre-2022), budget for software decode times of 100–200 ms per image and consider limiting AVIF usage to above- the-fold heroes rather than every image on the page.

• Chrome + Android 10+ on Qualcomm 888/8 Gen 1+: hardware AV1 decode is active; a 1 MP AVIF decodes in roughly 15–30 ms.
• Firefox on Windows 11 (non-GPU-accelerated): uses the dav1d software decoder; expect 60–100 ms for a 2 MP image on a mid-range CPU. Enable hardware acceleration in Firefox Settings → Performance to cut that in half.
• Safari on iPhone 15 Pro (A17 Pro): Apple's hardware AV1 block brings decode time to under 20 ms for a 2 MP image, on par with JPEG.
• Safari on Intel Mac (pre-M1): no hardware AV1, so Safari uses a software path; a 4 MP AVIF can take 250–400 ms. WebP is a faster choice for Intel Mac users when latency is critical.

The practical takeaway: AVIF is safe to deploy as a first-class format for modern devices from 2020 onward. For older hardware you still want a fallback, but the fallback is for the missing decoder, not for slow decode — any device old enough to lack AVIF support also lacks hardware AV1, so the two concerns align exactly.

Browser support covers roughly 96 % of global traffic as of late 2024 (Chrome + Edge + Firefox + Safari combined, per caniuse data). The remaining 4 % — primarily IE 11 holdovers in enterprise environments and un-updated iOS 15 devices — need a fallback. There are three standard patterns, each with different trade-offs.

• Pattern 1 — HTML <picture> element (recommended): Place the AVIF source first, then WebP, then JPEG as the final <img> fallback. The browser picks the first type it can decode without downloading the others. Example: a 1.2 MB hero JPEG becomes 310 KB as WebP and 190 KB as AVIF. Browsers that support AVIF save 85 % of bytes; older browsers still load correctly from the JPEG.
• Pattern 2 — server-side Accept header negotiation: Read the Accept request header. Chrome sends image/avif,image/webp,*/*;q=0.8; Safari 16+ sends image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8. Your CDN or image service can rewrite the URL to the best variant automatically, keeping your HTML clean. Cloudflare Images, Fastly, and imgix all support this natively with zero configuration changes to markup.
• Pattern 3 — JavaScript feature detection: Decode a 1×1 AVIF data URI with an Image object and check onload. Store the result in localStorage so detection only runs once per browser session. This is the slowest pattern (adds a ~5 ms detection step on first load) and is only worth it when you cannot use <picture> or server headers — for example, inside a CSS background-image.

For most websites, Pattern 1 is the right choice. It requires no server logic, works across all hosting setups, and costs nothing to implement. Patterns 2 and 3 are worth exploring when you have thousands of image variants and want to centralise format logic in your CDN rather than duplicating <picture> markup on every page. If you need to prepare a JPEG fallback today, the AVIF to JPG converter converts files directly in the browser with no upload required.