A smaller export is useful only if it keeps the image you need. In our 12-asset comparison, changing the asset, dimensions or compression mode changed the size tradeoff between AVIF and WebP.
Quick answer
Try both formats on representative assets and inspect the exported files. AVIF produced attractive small lossy candidates in this corpus, particularly for the synthetic illustrations, but its size advantage varied. When exact text or transparency mattered, lossless WebP was smaller than lossless AVIF in every tested pair. These findings apply to the recorded encoders and assets; they are not a universal ranking.
Contents
- What we compared
- What the example exports show
- Where smaller files changed the image
- Lossless changed the decision
- Encoding workflow and deployment
- How to choose for your assets
- Methods, evidence and limits
What we compared
We encoded 12 still-image masters at 1200 and 600 pixels on the long edge on 11 Oct 2026. Three photographs came from CC0 camera RAW samples: sky and treeline, a stone facade, and a dim ceiling with a lamp. We developed the RAW data into lossless 8-bit sRGB PNG masters. No embedded JPEG preview became a compression-test input.
The remaining nine assets were original synthetic fixtures: three flat or gradient illustrations, three text/UI-like layouts and three transparent cutouts. The UI fixtures are test patterns, not screenshots of a real application. The transparent set contains a soft disc, a badge with lettering and fine translucent lines; it does not represent the variety of product photography or hair cutouts.
Both codecs received the same preprocessed PNG at each size. We preserved aspect ratio, avoided upscaling and used Pillow’s Lanczos resizing. Alpha inputs retained their RGBA channels. The lossless comparisons refer to these resized reference pixels, not to reconstructing the full-resolution camera RAW.
For lossy WebP, we used libwebp 1.6.0 through Pillow 12.3.0 at quality 50, 65, 80 and 90 with method 6. AVIF used libavif 1.4.2 with libaom 3.14.1 at quality 40, 55, 70 and 85, speed 6 and one job. AVIF was 8-bit SDR, full range and 4:2:0; alpha quality was 100. Both formats included the same sRGB profile and excluded unrelated EXIF and XMP.
These quality numbers belong to different encoders. WebP 80 and AVIF 70 are not equivalent quality promises. We retained the full sweeps and inspected identical native-pixel crops across all eight lossy settings, plus complete 600-pixel views of those two starting exports. We did not establish perceptually matched pairs or run a human-rating panel.
What the example exports show
The table gives the byte counts for WebP 80 and AVIF 70 at both dimensions. It is a descriptive slice through the sweep, not a quality-normalized savings table. All 192 lossy outputs and the separate 24 lossless outputs are retained in the methods/results archive.
| Asset | 1200 WebP 80 | 1200 AVIF 70 | 600 WebP 80 | 600 AVIF 70 |
|---|---|---|---|---|
| photo-smooth | 56,956 | 71,205 | 15,376 | 19,213 |
| photo-texture | 81,180 | 83,206 | 31,930 | 33,247 |
| photo-lowlight | 5,666 | 3,140 | 2,196 | 1,866 |
| illustration-1 | 7,586 | 3,822 | 3,708 | 2,088 |
| illustration-2 | 13,848 | 9,379 | 6,944 | 4,102 |
| illustration-3 | 6,112 | 3,205 | 2,742 | 1,823 |
| text-1 | 26,306 | 22,019 | 11,602 | 11,967 |
| text-2 | 25,698 | 23,504 | 11,570 | 12,239 |
| text-3 | 43,844 | 36,149 | 19,520 | 18,960 |
| alpha-1 | 40,170 | 40,212 | 11,766 | 12,647 |
| alpha-2 | 11,896 | 10,096 | 5,950 | 5,346 |
| alpha-3 | 259,266 | 230,339 | 95,318 | 81,890 |
At 1200 pixels, the three photographic WebP examples ranged from 5,666 to 81,180 bytes; AVIF ranged from 3,140 to 83,206. The dim interior favored AVIF’s size, while the sky/treeline and facade examples were larger as AVIF at these settings. The photographs therefore do not support a single photographic saving percentage.
For the three illustration examples, WebP ranged from 6,112 to 13,848 bytes and AVIF from 3,205 to 9,379. Every AVIF example in this particular table was smaller. That makes AVIF worth trying on similar raster assets, provided you inspect the edges and gradient transitions before accepting the export.
Size could also change the apparent winner. Both monochrome text fixtures were smaller as AVIF at 1200 pixels but smaller as WebP at 600 pixels under these recipes. The soft transparent disc was almost tied at 1200 pixels—40,170 versus 40,212 bytes—and more clearly favored WebP at 600. Small files also include container and profile overhead; the image content is not the entire file.
Where smaller files changed the image
In the photo crops, low settings simplified stonework, softened carving and reduced fine detail in branches and sky. The architecture still looked recognizable at display size, but that is a different requirement from preserving a small carved feature. The dim ceiling was forgiving until attention moved to the lamp’s bright edge and lettering.
The synthetic color-bar illustration exposed smearing around high-contrast boundaries. The gradients showed stepped or mottled transitions at lower settings. A file that looks clean as a thumbnail can still have damage when it fills its intended space.
The text fixtures made the fidelity decision more concrete. Small glyphs developed halos or softened edges, and colored letters lost edge definition. Both lossy paths used 4:2:0 chroma, but we did not isolate chroma sampling from other encoder decisions. The smallest line was already tiny in the resized reference; resizing damage should not be blamed on the codec.
Transparency needs two backgrounds. We inspected the same alpha crops against white and dark gray. The soft disc had a dark fringe in the reference itself, so that fringe is not evidence of an encoding fault. Fine translucent lines changed hue and detail in the lossy views, even when the overall shape remained recognizable.
The comparison crops in the evidence archive retain the exact reference and decoded pixels, rectangle coordinates, source IDs, settings and background labels. Inspect those files alongside the full images; an isolated crop can miss a different weak area.
Lossless changed the decision
For text and alpha assets, we also ran separate lossless encodes. AVIF used explicit lossless mode, 4:4:4 and the identity color matrix. WebP used lossless mode with exact hidden-color preservation. We then decoded each output and compared every RGB or RGBA channel with its processed reference.
All 24 outputs passed exact pixel equality. This is a stronger quality match than our subjective lossy review: the reference pixels were the same after decoding. The following table shows the six asset pairs at 1200 pixels; the archive includes both dimensions.
| Asset (1200 px) | WebP bytes | AVIF bytes |
|---|---|---|
| text-1 | 48,114 | 146,924 |
| text-2 | 51,520 | 148,517 |
| text-3 | 99,550 | 229,479 |
| alpha-1 | 136,696 | 159,677 |
| alpha-2 | 13,940 | 37,560 |
| alpha-3 | 185,768 | 521,385 |
Lossless WebP was smaller in all 12 asset/size pairs. That is a result for this corpus and these implementations, not a claim that every lossless image will favor WebP. AVIF’s lossy advantages do not establish a lossless advantage.
The fine-line transparency fixture is particularly useful. At 1200 pixels, lossless WebP used 185,768 bytes, while its quality-80 lossy export used 259,266. At 600 pixels, the equivalent figures were 86,194 and 95,318. Here the exact output was also smaller. Testing only lossy settings would have missed a better candidate for this asset.
Encoding workflow and deployment
Our run records the actual options, backend versions, file hashes and decoded views. We did not benchmark encoding times, browser decoding, power use or page performance. A command-line speed setting is an encoder control; it is not a measured statement about how quickly a visitor sees an image.
The WebP encoder documentation separates quality, compression method and lossless behavior. libavif’s project documentation identifies the AV1 backend choices. If your CMS or image service uses another backend, preset, resizing step or metadata policy, reproduce the comparison there rather than copying our quality numbers.
MDN’s format guide lists support for both formats in current major browsers and describes picture-based fallbacks. Check the browsers and tools your audience actually uses. Keep a compatible fallback where required, and verify that the browser requests the intended source.
WordPress’s AVIF support note documents support from version 6.5, conditional on the host’s image-processing library. Its Site Health guidance shows where to check supported formats. Verify upload acceptance, generated sizes and the final front-end output on your own site; a browser’s ability to display AVIF does not prove the server can process it. We did not test a WordPress AVIF workflow for this article.
How to choose for your assets
- Start with several real assets from your site, including difficult text, gradients and transparent edges.
- Create the dimensions you actually deliver before comparing formats. Use the same source pixels for each candidate.
- Export several settings in each format. Open the results at the intended size and inspect identical native-pixel crops.
- Check transparency on the backgrounds the site uses. Compare lossless options when exact edges or documentary text matter.
- Choose the smallest file that meets your own fidelity requirement, then verify its CMS and browser delivery.
For a logo or icon that begins as vector artwork, revisit the asset choice before raster compression. Our SVG vs PNG guide explains when keeping vector geometry is the more useful decision.
Compression also cannot establish whether the image request starts early enough. Investigate discovery and loading behavior separately when a hero appears late. Our experiment measured files, not LCP improvements.
Methods, evidence and limits
Download the experiment evidence bundle (ZIP, 14.6 MB) for the processed inputs, original encoded outputs, measured results and encoding-command records. These files let you repeat the encoding comparison from the supplied inputs; original camera RAW files and internal research records are kept separately.
The corpus is small and deliberately varied; nine assets are synthetic. We used one configuration family per codec and a single subjective visual review without a calibrated display. Pixel-error metrics in the archive are auxiliary checks, not evidence of perceptual equivalence. We did not test HDR, wide gamut, animation, browser decode latency, energy or real-page speed.
The practical result is a comparison procedure you can repeat with your own images. Retain the master, the export settings and the reason you accepted a particular file. That record is more useful than applying one winning-format rule across an entire site.