WebP vs AVIF: The Modern Image Format War

June 18, 2026 · JPG.now Editorial · Format Comparisons

WebP and AVIF are both modern image formats designed to replace JPG for web delivery. Both achieve significantly smaller file sizes at equivalent quality. Both have broad browser support in 2026. Both have CDN tooling. And both come with trade-offs that matter in production. After running real conversions on a 500-image test set across photographic content, illustration, and screenshots, here is the honest comparison and the production-ready recommendation.

If you are a web developer, performance engineer, or e-commerce operator deciding which format to deploy in 2026, this is the practical guide. It covers compression results, browser support, encoding cost, CDN integration, and the production patterns that actually scale.

Background and context

WebP was developed by Google starting in 2010, based on the VP8 video codec. It was promoted aggressively through Chrome and Google's web tools, and reached majority browser support around 2018. AVIF was developed by the Alliance for Open Media, the same group behind the AV1 video codec, and reached production browser support starting in 2020. Both formats represent a generational improvement over JPG in compression efficiency, and both are now considered baseline expectations for performance-conscious web delivery.

The compression results

On a 500-image test set — 60 percent photographs, 25 percent illustrations and UI assets, 15 percent screenshots — converted from JPG quality 90 source files at matched perceptual quality:

JPG (baseline): average 412 KB per image
WebP (quality 80): average 268 KB per image — 35 percent smaller
AVIF (quality 65): average 178 KB per image — 57 percent smaller

AVIF wins on raw compression efficiency by roughly 30 percent over WebP. The gap is largest on photographic content and smallest on synthetic graphics. AVIF's advantage is most pronounced on smooth gradients and skin tones, where it preserves detail at file sizes WebP cannot match.

Format comparison

Attribute	JPG	WebP	AVIF
Avg file size (500-img test)	412 KB	268 KB	178 KB
Compression vs JPG	baseline	-35%	-57%
Browser support 2026	100%	99.7%	~96%
Encoding speed	Fast	Medium	Slow (8-20x WebP)
Decoding speed	Fast	Fast	Medium
Lossless mode	No	Yes	Yes
Alpha (transparency)	No	Yes	Yes
Animation	No	Yes	Yes
HDR support	No	Limited	Yes (10/12-bit)

Browser support in 2026

WebP is universal. Chrome, Firefox, Safari, Edge, Opera, and every mobile browser have supported it for years. Older Safari versions on iOS 13 and below do not, but that user base is below 0.3 percent globally.

AVIF support is now broad but not universal. Chrome and Firefox have supported AVIF since 2020. Safari added support in iOS 16 (September 2022). Edge supports it. Opera supports it. The combined gap is older Safari on macOS, some embedded browsers, and a handful of in-app browsers (mostly older versions of Facebook's and LinkedIn's embedded webviews). The right number for 2026 production sites is roughly 96 percent global AVIF support.

Most production sites serve AVIF with WebP and JPG fallbacks via the HTML picture element. The CDN or framework handles the negotiation transparently.

Encoding speed and CPU cost

This is where AVIF's advantage gets complicated. AVIF encoding is significantly slower than WebP encoding — roughly 8 to 20 times slower at default settings. A WebP encode of a 12-megapixel photo on modern hardware takes 200 to 400 milliseconds. The same image to AVIF takes 3 to 8 seconds at the encoder's default speed setting, or 15 to 30 seconds at slow-but-better-quality settings.

For a static site with a build step, the encoding time is paid once and the savings accrue forever — no contest, AVIF wins. For a user-upload site where images are processed in real time (a marketplace, a social platform, a CMS), the encoding cost matters. Many sites use WebP for user uploads and AVIF only for hero images and editorial content.

Decoding speed

WebP decodes slightly faster than AVIF on most devices, but both are fast enough on modern hardware that the difference is invisible to users. On low-end Android devices and old iOS hardware, AVIF decoding can introduce a noticeable lag on image-heavy pages — under 100 milliseconds per image, but cumulative across a long feed.

CDN tooling

Cloudflare Images, Cloudinary, Imgix, AWS CloudFront with Lambda@Edge, Vercel's image optimizer, Next.js Image, and most modern CMSes all support automatic AVIF and WebP delivery with JPG fallback. The negotiation is based on the browser's Accept header. You upload one source file — usually JPG or PNG — and the CDN serves AVIF to browsers that accept it, WebP to browsers that accept that, and JPG to everyone else.

This is the production-ready architecture in 2026. You almost never want to manage three sets of files manually.

Step-by-step walkthrough: deploying AVIF + WebP + JPG

Audit current images. Identify the JPG and PNG sources you want to optimize.
Decide build-time or runtime. Static sites: build-time. Dynamic sites: CDN runtime.
For build-time, run AVIF and WebP encoders. Output three versions of each image.
Configure your HTML. Use the picture element with type-based fallback.
Set quality targets. AVIF q65, WebP q80, JPG q85 — matched perceptual quality.
Test on representative browsers. Chrome (AVIF), Safari iOS 15 (WebP), legacy Safari (JPG).
Measure Core Web Vitals. LCP should improve materially with AVIF deployment.
Set up build cache. Avoid re-encoding unchanged images on every build.

When to pick each

Pick WebP when you need universal browser support without fallbacks, when encoding speed matters (user uploads, real-time pipelines), when your CDN does not support AVIF, or when your audience skews toward older devices. WebP is the safe default. Convert JPG masters with the JPG to WebP converter for one-off files or in batch.

Pick AVIF when file size is the primary concern, you can afford the encoding cost (static site, build-time conversion), your CDN handles fallbacks, and your audience is on modern devices. AVIF wins on Core Web Vitals — its smaller file sizes directly improve Largest Contentful Paint and total transfer size. Convert with the JPG to AVIF converter.

Pick both for any serious production site. AVIF as the primary, WebP as the fallback for browsers that do not support AVIF, JPG as the universal fallback. The picture element handles the negotiation.

The HTML pattern

The standard pattern looks like:

source type="image/avif" srcset="image.avif"
source type="image/webp" srcset="image.webp"
img src="image.jpg" alt="..."

Wrapped in a picture element. The browser picks the first format it supports. No JavaScript required, no Accept header negotiation, no CDN dependency.

Real-world examples

Acme Tools, an e-commerce shop. Migrated 12,000 product images from JPG to AVIF+WebP+JPG via Cloudflare Images. Page weight dropped 48 percent. Largest Contentful Paint improved by 1.2 seconds on mobile. Conversion rate climbed 8 percent.

The Mountaineer blog. Static Hugo site with 800 hero images. Build-time AVIF and WebP encoding via cwebp and cavif. Build time grew from 90 seconds to 14 minutes, but bandwidth bill dropped 60 percent and Core Web Vitals went from yellow to green across all pages.

FlatField marketplace. User-upload-heavy site. Used WebP only for user uploads (real-time encoding cost mattered) and AVIF for the static category headers and brand assets. Hybrid approach saved 35 percent bandwidth without slowing upload pipelines.

What about going back to JPG

Sometimes you have WebP or AVIF files and need to convert them back to JPG — for a tool that does not accept modern formats, for a print lab, for an insurance portal. The WebP to JPG converter and AVIF to JPG converter handle these direct conversions. Be aware that both directions are lossy if you start from a lossy source — there is no way to recover detail that the original WebP or AVIF encoder discarded.

Common mistakes and how to avoid them

Encoding AVIF at default speed settings on a static site. Misses major quality wins. Fix: use slower speed settings (cavif --speed 4) for build-time encoding.
Comparing file sizes at the same quality number. WebP q80 and AVIF q80 are different. Fix: match perceptual quality with side-by-side comparison.
Deploying AVIF without a WebP fallback. Some browsers still need WebP. Fix: always include WebP in the picture element.
Trying to use AVIF for real-time user-upload pipelines. Encoding cost crushes the server. Fix: WebP for uploads, AVIF for editorial.
Not testing on iOS Safari. Older versions lack AVIF. Fix: verify on iOS 15 and below.
Forgetting the JPG fallback. Embedded browsers and in-app webviews break. Fix: always include the img src JPG.

Advanced tips

Use libvips or sharp in Node.js for fast batch encoding across formats.
Build a cache key based on source hash + quality setting to avoid re-encoding.
For hero images, encode at multiple resolutions (srcset) for responsive delivery.
Test perceptual quality with SSIMULACRA2 or DSSIM rather than eyeballing.
For animated content, AVIF and WebP both beat GIF — convert with the GIF to JPG for static frames or use APNG/AVIF directly.
For Lighthouse and Core Web Vitals optimization, AVIF on the LCP image yields the biggest impact.
For maximum bandwidth savings, combine AVIF with HTTP/3 and Brotli compression on HTML.

FAQ

Will AVIF replace JPG entirely?

Not soon. JPG remains the universal lingua franca for image exchange. AVIF is a delivery optimization.

What about JPEG XL?

Promising but limited browser support. Chrome removed support in 2022; Safari has experimental support. Not production-ready in 2026.

Does AVIF support animation?

Yes — AVIF is based on AV1, which supports video. Animated AVIF works in modern browsers.

Is WebP lossless mode useful?

Yes for screenshots, UI assets, and synthetic images. For photographs, lossy WebP is the better choice.

Can I edit AVIF and WebP directly?

Most modern editors support both. Photoshop added AVIF in 2022. GIMP and Affinity Photo also support both.

Does mobile data save more with AVIF?

Yes — smaller files mean less radio time, which directly affects battery and cellular data.

What about server-side cost?

AVIF encoding is CPU-intensive. Static sites pay once at build. Dynamic CDN services amortize it across all visitors.

The 2026 verdict

WebP is the safe production default. AVIF is the performance ceiling. Most serious sites should serve AVIF as primary, WebP as fallback, and JPG as universal fallback. Convert your sources once with the JPG to WebP converter and the JPG to AVIF converter. If file size matters more than encoding speed, lean AVIF. If encoding speed matters more, lean WebP. If you are running a static site with a build step, do both — the cost is paid once and the bandwidth savings compound for every visitor for the life of the site.

For everything that still needs a JPG output — print, email attachments, legacy systems — keep the JPG compressor in the workflow. JPG is not going away. It is just no longer the right format for the front page of a fast website.

Why JPEG XL did not win

JPEG XL was developed as a designated successor to classic JPG, with better compression, lossless re-encoding from existing JPGs, and broader feature support. Chrome added experimental support, then removed it in 2022, citing insufficient adoption. Safari has experimental support behind a flag. Firefox has not committed.

The reason JPEG XL did not win is largely strategic: Google's vested interest in WebP and the AV1 ecosystem (which underlies AVIF) meant Chrome had less incentive to promote a competing format. Without Chrome support, web adoption was effectively blocked. JPEG XL remains technically excellent but practically marginal.

The economics of format adoption

Every format transition costs bandwidth, encoding compute, and engineering effort upfront and saves bandwidth in perpetuity. The math: a site serving 10 million image views per month at 400 KB JPG average is moving 4 TB monthly. Switching to AVIF at 175 KB average saves 2.25 TB per month — roughly $200 to $400 in CDN bandwidth costs depending on the provider.

For high-traffic sites, the AVIF migration pays for itself within months. For low-traffic sites, the engineering effort may exceed the savings. The break-even point is roughly 50,000 monthly image views; below that, sticking with optimized JPG is fine.

Quality calibration across formats

Quality settings are not portable between formats. JPG quality 85 does not equal WebP quality 85 does not equal AVIF quality 85. Each codec uses different internal quantization, so the numbers represent different things.

The right way to compare is perceptual: produce outputs that look the same to the eye (or to an objective metric like SSIMULACRA2 or DSSIM), then compare file sizes. The numbers in the introduction (JPG q90, WebP q80, AVIF q65) come from this kind of matching exercise on a 500-image test set.

Lossless mode considerations

Both WebP and AVIF support lossless compression mode. WebP lossless typically beats PNG by 20 to 25 percent on the same content. AVIF lossless is roughly comparable to WebP lossless, sometimes slightly better. For UI assets, screenshots, illustrations with sharp edges, and any content where lossless matters, both formats are excellent PNG replacements.

JPG has no lossless mode in standard usage. JPEG XL has lossless mode and can losslessly re-encode existing JPGs at smaller file sizes, but browser support is limited.

HDR and wide color gamut

AVIF supports 10-bit and 12-bit color depth and HDR transfer functions natively. WebP supports 8-bit only. For HDR content (the small but growing share of phone-captured photos with HDR metadata), AVIF preserves the HDR; WebP collapses it to SDR.

This matters increasingly for iPhone-captured content. iOS 15+ captures HDR photos by default, and modern displays (iPhone 12 Pro+, recent MacBook Pros, recent iPads) can display them. AVIF delivery preserves the HDR experience; JPG and WebP do not.

Codec licensing

WebP is royalty-free under Google's open license. AVIF is royalty-free under the Alliance for Open Media license. Both are usable in commercial products without payment. JPEG XL is also royalty-free.

This is part of why AVIF gained adoption faster than its predecessor HEIC (which has patent royalty entanglements). The royalty-free status removed a major adoption barrier.

Server-side encoder choices

Encoder	Format	Speed	Quality at default
libwebp / cwebp	WebP	Fast	Good
libavif / cavif	AVIF	Medium	Excellent
libaom (reference)	AVIF	Slow	Best
rav1e	AVIF	Faster than libaom	Very good
SVT-AV1	AVIF	Fast (multi-threaded)	Very good
libjpeg-turbo	JPG	Very fast	Good (baseline)
mozjpeg	JPG	Fast	Better than libjpeg-turbo

For maximum AVIF quality at acceptable speed in 2026, SVT-AV1 is the practical choice for static-site batch encoding. libaom is the slow-but-best option for highest-stakes hero images.

SEO and search ranking

Google considers image format and file size as part of Core Web Vitals scoring, which influences search ranking. Sites that deploy AVIF (or WebP) and achieve Largest Contentful Paint under 2.5 seconds rank higher than equivalent JPG-only sites. The effect is small per page but compounds across thousands of indexed pages.

Google's PageSpeed Insights explicitly flags "Serve images in next-gen formats" as a recommendation. Sites still serving JPG-only get this warning. Sites serving AVIF with WebP fallback pass it cleanly.

Future-proofing your deployment

The HTML picture element pattern is forward-compatible. When the next format emerges (JPEG XL likely, or some other contender), you can add a new source line above the AVIF source without breaking existing browsers. The format negotiation pattern is the right architectural choice regardless of which formats win.

If you are starting fresh today, build the picture element pattern from day one. Even if you only have JPG sources, the wrapping pattern means future format additions are a simple template update.

← All articles