WebP and AVIF are the two modern image formats worth taking seriously in 2026. Both beat JPEG and PNG on file size, both have transparency support, both are royalty-free, and both are supported by every major browser that currently ships. On paper, they look like alternatives — but in practice each one wins in different places, and picking the wrong one for a given workload can either bloat your bandwidth bill or blow your encoding budget. This guide is the head-to-head.
1. The quick summary
AVIF wins on file size for photographic content, typically producing files 20–30% smaller than WebP at the same visual quality. WebP wins on encoding speed, often by a factor of 10× or more, which matters enormously for real-time pipelines like user-uploaded avatars. Both formats are well-supported in current browsers; the lingering compatibility concern with AVIF is iOS 15 and older.
For a CDN-delivered asset that's encoded once and served millions of times, AVIF's file-size advantage is overwhelming — you pay the encoding cost once and save bandwidth forever. For an image that's encoded on demand and served rarely, WebP's speed is usually the better trade. Most production sites in 2026 use both, serving AVIF when supported and falling back to WebP when not.
2. How each format works under the hood
WebP is based on the VP8 video codec (for lossy mode) and a custom lossless algorithm (for VP8L). Its compression model is conceptually similar to JPEG — block-based transform coding with quantization — but with more sophisticated prediction and a larger block-partitioning palette. Google released WebP in 2010 and refined it steadily through the 2010s; the ecosystem of encoders is mature, stable, and fast.
AVIF is a still-image profile of the AV1 video codec, standardised in 2019. AV1 is a generation ahead of VP8: it supports much larger block sizes (up to 128×128), better intra-prediction modes, film grain synthesis, and a transform palette that includes asymmetric DCT variants. The improvements are real, but they come at a cost — the encoder has more knobs to tune and a larger search space to explore. A well-tuned AVIF encode extracts genuinely more compression than WebP; a poorly-tuned one is slow without the benefit.
3. File-size benchmarks
Here's what you can typically expect on a 1920×1280 photographic image at roughly equivalent visual quality (SSIM ~0.95):
| Format | Typical size | Encode time (ref) | vs WebP |
|---|---|---|---|
| WebP (q=80) | ~340 KB | ~0.3 s | Baseline |
| AVIF (fast preset) | ~290 KB | ~1.5 s | −15% |
| AVIF (balanced) | ~240 KB | ~5 s | −30% |
| AVIF (best quality) | ~210 KB | ~30 s | −38% |
Numbers vary by ±20% based on content type, but the ordering is stable across photographic test images. On flat graphics and UI content the AVIF advantage is smaller; on high-resolution photography it's often larger.
4. Browser support in 2026
WebP: universal across all current browsers. Every version of Chrome since 2010, Firefox since 2019, Safari since iOS 14 / macOS Big Sur (2020), and Edge since the Chromium switch. If a browser is current enough to support HTTP/2, it supports WebP.
AVIF: supported by Chrome 85+ (2020), Firefox 93+ (2021), Safari 16+ (September 2022), and all current Edge versions. The gap is iOS 15 and earlier, which is a small but non-zero slice of mobile traffic in 2026 — a few percent in most analytics. Desktop and Android tails are even thinner. For public-facing sites, the practical answer is: ship AVIF with a WebP fallback and you cover essentially every user.
5. The correct HTML delivery pattern
Use a <picture> element with multiple source types, in order from most preferred to most compatible:
The browser picks the first source type it can decode. The final <img> fallback is what renders for browsers that don't support <picture> at all (essentially no one in 2026, but the attribute is required syntactically and provides a fallback for image-lazy-loading tools and crawlers).
6. Decision tree
- Static CDN-delivered assets, encoded once → AVIF (with WebP fallback). You pay the encoding cost once and save bandwidth on every delivery.
- On-demand user-generated content → WebP. The fast encoder matters more than the last 20% of file-size savings when you're processing millions of uploads.
- Small icons and UI elements (<200 px) → WebP (lossy or lossless) or PNG. AVIF's container overhead erases its size advantage on very small images.
- High-dynamic-range (HDR) content → AVIF. It natively supports 10 and 12-bit colour and wide colour gamuts; WebP tops out at 8-bit.
- Animated content → WebP animation or MP4/AV1 video. AVIF technically supports animation via animated AVIF, but encoder and browser support is less mature than WebP animation.
- Legacy systems without
<picture>support → JPEG fallback remains essential. Set it as the defaultsrc.
Convert between WebP and AVIF
OnlyFormat's browser-based converters handle all modern image formats. Files never leave your device.
Frequently asked questions
Q. Is AVIF always smaller than WebP?
A. On photographic content, yes — typically 20–30% smaller at the same perceived quality, sometimes more. On small images (icons, thumbnails under about 300×300), the size difference narrows and occasionally reverses because AVIF has a larger container overhead. For very small UI elements, WebP or PNG is usually the pragmatic winner.
Q. Why is AVIF encoding so slow?
A. AVIF uses the AV1 video codec for its intra-frame compression, and AV1 was designed for video where encoding can take minutes per minute of footage. The rate-distortion optimisation that gives AVIF its small file sizes requires searching a large space of possible block partitions and coding modes. Fast AVIF encoders trade compression ratio for speed, but the trade-off is real — a tuned AVIF encode can take 10× longer than a WebP encode of the same image.
Q. Can I serve AVIF to all users safely in 2026?
A. Not alone — you should always pair it with a fallback. Safari added AVIF in version 16 (iOS 16, September 2022), so users on iOS 15 or earlier cannot decode AVIF at all. The correct pattern is a <picture> element with AVIF as the primary source and WebP or JPEG as the fallback.
Q. Does AVIF support transparency?
A. Yes. AVIF supports an alpha channel at full quality without the colour-bleeding issues WebP lossy has with transparency. For logos, UI assets, and any image with transparent areas, AVIF often produces noticeably better results than WebP at the same file size.
Q. What about JPEG XL vs AVIF?
A. Technically, JPEG XL outperforms AVIF on many metrics — faster encoding, progressive decoding, and better quality-per-byte on some content types. The problem is browser support: Chrome removed the flag-gated JPEG XL support in 2022, and adoption is lukewarm. As of 2026, JPEG XL is shipping default in Safari but remains behind a flag or missing in Chrome and Firefox. Don't ship JPEG XL as the only format on a production site until mainstream support lands.
References
- AOMediaCodec — AV1 Image File Format (AVIF) specification
- ISO/IEC 23008-12 — HEIF (shared container with AVIF)
- Google WebP project documentation —
developers.google.com/speed/webp - MDN Web Docs — <picture> element
- caniuse.com — AVIF / WebP browser support tables
- libavif —
github.com/AOMediaCodec/libavif - libwebp —
chromium.googlesource.com/webm/libwebp
About the OnlyFormat Editorial Team
OnlyFormat's editorial team is made up of working web developers and image-workflow engineers who ship file-conversion tooling for a living. Every guide is reviewed against primary sources — W3C/WHATWG specifications, IETF RFCs, MDN Web Docs, ISO/IEC media standards, and the official documentation of libraries we actually use in production (libwebp, libjpeg-turbo, libavif, FFmpeg, pdf-lib). We update articles when standards change so the guidance stays current.
Sources we cite: W3C · WHATWG · MDN Web Docs · IETF RFCs · ISO/IEC · libwebp · libavif · FFmpeg · pdf-lib