Evaluated January 2026: serve AVIF first, keep WebP as the fallback, and keep HEIF out of your delivery path entirely. AVIF is decodable by roughly 94–96% of global browser traffic and lands photographic images 15–30% smaller than WebP at matched perceptual quality. WebP covers the remaining few percent plus older in-app webviews. HEIC decodes only in Safari 17 and later, which makes it an ingest format rather than a delivery format. This image format comparison scores the three on compression, decode cost, encode cost and licensing, then shows how to pick one per request at the edge without shredding your cache hit ratio.
The short version, by workload:
One correction worth making before going further, because it derails a lot of format arguments: HEIF is a container, not a codec. HEIC is HEVC bitstreams inside HEIF. AVIF is AV1 bitstreams inside a container derived from the same ISO base media file format family. So "AVIF vs HEIF" is a category error; the real comparison is AV1 intra-frame coding versus HEVC intra-frame coding, wrapped in near-identical boxes.
Six criteria carry the decision. Everything else is noise at delivery scale.
Assumptions used throughout: photographic content at 800–2400 px on the long edge, quality targeted at the "visually lossless enough for e-commerce" band, and support percentages drawn from public 2025–2026 browser usage measurements. Ranges are ranges because content type moves these numbers more than any encoder flag does.
| Format | Browser support (2026) | Size vs baseline JPEG | Decode cost (1 thread) | Encode cost | Licensing | Best role |
|---|---|---|---|---|---|---|
| AVIF (AV1 in HEIF-derived container) | Chrome 85+, Firefox 93+, Safari 16+; ~94–96% of traffic | 40–50% smaller | ~2–5x JPEG | High: 10–50x mozjpeg depending on speed preset | Royalty-free (AOMedia) | Primary delivery format for photographic web images |
| WebP | Universal since Safari 14 (2020); ~97–98% | 25–34% smaller (lossy) | ~1.2–1.5x JPEG | Low: comparable to JPEG at method 4 | Royalty-free | Fallback tier, small assets, lossless replacement for PNG |
| HEIC (HEVC in HEIF) | Safari 17+ only; ~18–20% | 40–50% smaller | ~1.5–3x JPEG, often hardware-accelerated on Apple silicon | Moderate; hardware encoders on capture devices | HEVC patent pools; multiple licensors | Capture and ingest only |
| JPEG XL | Safari 17+; no default Chrome decode as of early 2026 | 30–60% smaller, best at high quality | ~1–2x JPEG, parallelizes well | Low to moderate | Royalty-free | Archival, print pipelines, lossless JPEG recompression |
| JPEG (mozjpeg, 4:2:0) | 100% | Baseline | Baseline; progressive rendering | Baseline | Royalty-free | Universal floor, email, scrapers, ancient webviews |
The single conclusion from this table: only AVIF and WebP are viable web delivery formats in 2026, and the choice between them is a decode-cost-versus-bytes trade rather than a support question.
AVIF. Best compression per byte of the three at web-relevant quality levels, plus 10-bit, wide gamut, HDR transfer functions, full alpha and 4:4:4 chroma if you need it. Honest limitation: no progressive rendering, so a slow connection shows nothing until enough of the image has arrived, and encode cost is high enough that batch re-encoding a large library is a scheduled job, not a background task. Very large images can also spike decoder memory on low-end devices unless the encoder tiles them.
WebP. Fifteen years old, universally supported, cheap to encode and cheap to decode, and its lossless mode still beats optimized PNG by roughly 25% on flat graphics. Honest limitation: lossy WebP is 4:2:0 8-bit only, which visibly smears saturated red and orange edges — colored text over colored backgrounds is where it fails. Above roughly quality 90 it also becomes inefficient relative to a well-tuned JPEG.
HEIF and HEIC. Excellent compression, hardware encode and decode on hundreds of millions of Apple devices, and a rich container model with depth maps, bursts and image sequences. Honest limitation: HEVC royalty obligations and single-browser support kill it for delivery. Its real role is ingest, and your upload pipeline needs an HEVC-capable decoder plus an orientation and color-profile normalization step before it hands frames to your encoder farm.
In 2026, AVIF typically delivers photographic web images 15–30% smaller than WebP and 40–50% smaller than baseline JPEG at matched perceptual quality, while costing roughly 2–5x more CPU to decode on a single thread. HEIC compresses within a few percent of AVIF but decodes only in Safari 17 and later, which rules it out as a delivery format for the open web.
That decode multiplier matters when it lands on the main thread of a mid-range Android device already busy hydrating a framework. On low-end hardware, expect a full-viewport AVIF at roughly 1920 px wide to take tens of milliseconds to decode where a JPEG takes single digits (estimate, based on public 2025 mobile measurements and highly dependent on tiling and thread count). For one LCP hero, the byte savings win comfortably. For a grid of 60 thumbnails decoded simultaneously, the arithmetic can flip, which is the real argument for keeping WebP on your small-asset tier instead of converting everything to AVIF because a lint rule said so.
Two viable patterns. Distinct URLs with a type-qualified source list in markup pushes the decision to the browser, keeps every variant independently cacheable, and requires no negotiation logic — at the cost of template changes and a heavier HTML payload. Content negotiation on the Accept request header keeps one canonical URL and works for images referenced from CSS, but introduces a cache-key problem.
The problem is Vary. Responding with Vary set to Accept is correct HTTP, but real Accept strings differ across browsers and versions, so a naive cache fragments a single image into dozens of entries and your hit ratio falls. The fix is to normalize the header into a small token before it touches the cache key, so you hold exactly three copies: AVIF, WebP, JPEG.
map $http_accept $img_variant {
default "jpg";
"~*image/avif" "avif";
"~*image/webp" "webp";
}
location /img/ {
proxy_cache_key "$scheme$request_method$host$uri$img_variant";
proxy_set_header X-Img-Variant $img_variant;
add_header Vary Accept;
}Whether that normalization runs on your origin tier or on the CDN determines your origin offload. If the CDN cannot normalize, every Accept permutation becomes a separate origin fetch. BlazingCDN, for example, allows per-path cache-key and response-header configuration, so a normalized variant token can key the AVIF, WebP and JPEG copies of one URL without the Vary explosion; the same capability is worth verifying explicitly during any image optimization CDN feature evaluation rather than assuming it.
Assumptions, stated: a catalog serving 200 TB per month of WebP image egress, AVIF conversion yielding a 22% average byte reduction, and an assumed blended CDN rate of $5–10 per TB.
Savings: about 44 TB per month, or $220–440 per month. Re-encoding a library of 10 million derivatives with a modern AV1 encoder at a mid speed preset costs roughly 2,000–6,000 core-hours (estimate), which is a few hundred dollars of preemptible compute once. Payback is inside two months, and the delta grows linearly with traffic — at 2 PB per month of image egress the same 22% is 440 TB, which is where the line item starts appearing in infrastructure reviews.
The honest read: at moderate volume the bandwidth saving is small money. The reason to ship AVIF is the 100–400 ms LCP improvement on mobile connections and the mobile data you stop charging to your users' plans. Treat egress savings as the tiebreaker, not the business case.
| Workload | Primary | Fallback | Note |
|---|---|---|---|
| E-commerce product imagery | AVIF | WebP | Use 4:4:4 for garments with fine patterns |
| News and editorial LCP hero | AVIF | Progressive JPEG | Progressive JPEG fallback hides slow-link latency |
| Thumbnail grids and sprites under 8 KB | WebP | JPEG or PNG | AVIF overhead and decode count outweigh gains |
| UGC photo uploads | HEIC at ingest | JPEG at ingest | Transcode to AVIF and WebP; never re-serve HEIC |
| HDR and 10-bit photography | AVIF | SDR JPEG | WebP cannot carry 10-bit or PQ/HLG transfer |
| Email and social preview cards | JPEG | PNG | Scrapers and mail clients still fail on modern formats |
The pattern across every row: AVIF wins wherever one large image dominates the render, and WebP or JPEG wins wherever compatibility or decode count dominates.
Yes for photographic images above roughly 20 KB, where AVIF is typically 15–30% smaller at matched perceptual quality. WebP remains the better pick for small assets, flat graphics needing lossless, and any pipeline where encode CPU is the constraint. Ship both and negotiate per request; the two are complements, not competitors.
Only Safari 17 and later renders HEIC images natively, covering roughly 18–20% of global browser traffic. Chrome, Edge and Firefox do not, largely because of HEVC licensing rather than technical difficulty. Treat HEIC as an ingest format from Apple devices and transcode it to AVIF or WebP before delivery.
Use type-qualified sources in markup when you control the templates and want per-variant cacheability with no Vary handling. Use Accept negotiation when images are referenced from CSS or legacy templates you cannot change. If you negotiate, normalize Accept into a three-value variant token before the cache key, or the cache will fragment.
Roughly 10–50x the CPU of an optimized JPEG encode, depending on the encoder speed preset and thread count. At mid presets a 2-megapixel image takes on the order of one second per core. Batch it asynchronously, cache aggressively, and never encode AVIF synchronously in a request path.
Yes, as the fallback tier and the small-asset format. WebP covers roughly 97–98% of traffic, decodes at about 1.2–1.5x JPEG cost, and its lossless mode beats optimized PNG by around 25% on flat graphics. Dropping it entirely leaves older in-app webviews and some embedded clients on JPEG.
Pick 50 images that represent your real traffic mix, not a stock photo set. Encode each at AVIF, WebP and mozjpeg targets tuned to the same perceptual score, then record three numbers per format: transferred bytes, decode time measured through browser performance timing on a throttled mid-range mobile profile, and LCP on your actual template. Then check one operational metric that most teams miss: cache hit ratio on your image paths before and after enabling negotiation. If it drops more than a point or two, your variant key is wrong, not your format choice. Post your byte-versus-decode numbers to your team channel and let the data pick the tier boundary.