AVIF sub-sizes are larger than WebP at the default quality of 82

Bug Description

AVIF is the default output format when the server supports it, but at the default quality of 82 the AVIF sub-sizes are larger than WebP, and often larger than the JPEG they replace. With "Output fallback images" enabled, webp_uploads_should_discard_additional_image_file() then deletes most AVIF sub-sizes for not being smaller than the JPEG, and the site serves only JPEG. Choosing AVIF gives a worse result than choosing WebP.

Encoder	Affected since	Why
GD	WordPress 6.5	`imageavif()` has always received quality 82.
Imagick	WordPress 6.7	Before 6.7 the quality never reached the AVIF encoder, so libheif's default of 50 applied. r59247 (#61614) fixed that, and AVIF files grew 2.7 times with no settings change.
Browser (client side media processing)	WordPress 7.1	The `image_quality` REST field resolves `wp_editor_set_quality` for the output type, so the browser also encodes at 82.

The format is not the problem. At the same visual quality, AVIF is smaller than both JPEG and WebP (see the results below). The problem is that quality 82 means something different for each format.

Steps to reproduce

Use WordPress 6.7 or later on a server where Imagick or GD can encode AVIF, with Modern Image Formats active.
Go to Settings > Media, set "Image Format" to WebP and upload a photo (for example this JPEG).
Set "Image Format" to AVIF and upload the same photo again.
See that the AVIF sub-sizes in the uploads folder are larger than the WebP ones.
Enable "Output fallback images" and upload the same photo again.
See that most sub-sizes have no AVIF file, only JPEG.

Result

Tested on a fresh site with the official wordpress:php8.3-apache Docker image (Imagick 7.1.1-43 and GD) and the plugin from wordpress.org. The editor was forced through wp_image_editors. Four JPEG photos were uploaded with wp media import: the one above, kodim05, kodim23 and leaves.jpg. Plugin 2.6.0 is used on both 6.6.2 and 6.7, so only core changes between them.

WordPress	Plugin	Editor	AVIF larger than WebP	Median AVIF size vs WebP	AVIF discarded with fallback on
6.6.2	2.6.0	Imagick	0 of 11	57%	0 of 11
6.6.2	2.6.0	GD	11 of 11	139%	9 of 11
6.7	2.6.0	Imagick	11 of 11	138%	8 of 11
6.7	2.6.0	GD	11 of 11	139%	9 of 11
7.1.4	2.7.1	Imagick	11 of 11	138%	8 of 11
7.1.4	2.7.1	GD	11 of 11	139%	9 of 11

For example, the medium size of the first photo on 7.1.4 with Imagick is 15,369 bytes as JPEG, 12,208 as WebP and 17,153 as AVIF.

Cause

Core's WP_Image_Editor::get_default_quality() returns 86 for WebP and 82 for everything else, including AVIF. The plugin's webp_uploads_modify_webp_quality() changes only WebP, to 82.

No image format defines what a 0 to 100 quality means. Each encoder library turns the number into its own compression setting, so quality 82 gives AVIF much more detail (and bytes) than it gives JPEG or WebP:

Library	What quality 82 becomes	Source
libjpeg-turbo (JPEG)	Quantization tables scaled to 36%	`jpeg_quality_scaling()`
libwebp (WebP)	VP8 quantizer about 17 of 127	`QualityToCompression()`, `VP8SetSegmentParams()`
PHP's libgd (AVIF with GD)	AV1 quantizer 11 of 63	`quality2Quantizer()`, `gdImageAvifCtx()`
libheif (AVIF with Imagick and the browser)	AV1 quantizer 11 of 63	`encoder_aom.cc`

AVIF tools default well below 82: avifenc 60, PHP imageavif() 52, libheif 50, sharp 50 and Squoosh 50.

Before 6.7, Imagick only called setImageCompressionQuality(), but ImageMagick's AVIF coder reads the value set by setCompressionQuality() and skips setting the quality when it is undefined. r59247 was a correct fix that exposed 82 as too high for AVIF.

Which AVIF quality to use

Short answer

Where	Goal	Proposed AVIF quality	Result
Core	Look as good as JPEG 82, the WordPress default for JPEG	74	Looks at least as good as JPEG 82 on 83% to 97% of generated images, at about three quarters of the JPEG size.
Modern Image Formats	Look as good as WebP 82, the plugin's WebP quality	70	Looks at least as good as WebP 82 on 79% to 94% of generated images, and is still 6% to 7% smaller than WebP 82.

The ranges cover the three editors (GD, Imagick and the browser). The details are below.

How it was tested

Images. 384 openly licensed images of three kinds:

Kind	Images	Source
Photos	24	Kodak Lossless True Color Image Suite
Photos	41	CLIC 2020 professional validation set (CLIC)
Photos and some graphics	250	CID22 by Cloudinary
Photos	4	The plugin's test images: `leaves.jpg`, `paint.jpeg`, `car.jpeg`, `dice.png`
Diagrams	40	Featured diagrams on Wikimedia Commons, rendered to PNG
Screenshots	20	Pages on en.wikipedia.org and developer.wordpress.org, half at normal and half at 2x (retina) resolution
Screenshots	5	`screenshot.png` of the default themes Twenty Twenty-One to Twenty Twenty-Five

The full list of files, with credits, is in the benchmark repository.

Encoding. Each image went through the same steps WordPress uses, with the editor that does them on a real site:
- GD and Imagick, through WP_Image_Editor_GD and WP_Image_Editor_Imagick from WordPress 7.1.4.
- The browser, through wasm-vips 0.0.19 with the settings @wordpress/vips uses.
Every size WordPress generates was saved as JPEG 82, WebP 70 to 94 and AVIF 50 to 90. That covers thumbnail, medium, medium_large, large, 1536x1536, 2048x2048 and the full size (scaled to 2560 when larger). This gives 1,463 generated images per editor and 153,615 encoded files in total.
Server software. The official wordpress:php8.3-apache image: Debian 13, PHP 8.3, ImageMagick 7.1.1-43 with libheif 1.23.6, libavif 1.2.1 and libaom 3.12.1.
Scoring. Each encoded file was compared with the uncompressed version of the same image using three image quality metrics:
VMAF was also measured. It is left out of the decision because it is designed for video. Against JPEG 82 it asks for a higher AVIF quality (74 to 80) than the three image metrics do. Against WebP 82 it agrees with them.

How to read the tables

An AVIF file looks at least as good as the JPEG (or WebP) when all three metrics score it equal or better. For example, "83%" for GD means that 83 of every 100 generated images from GD look at least as good as the JPEG 82 version. File size is the median AVIF size compared with the JPEG (or WebP) file of the same image. 100% is the same size, and 72% means 28% smaller.

AVIF compared with JPEG 82 (the goal for core)

How often AVIF looks at least as good as JPEG 82 (higher is better):

Format and quality	GD	Imagick	Browser
AVIF 66	50%	48%	34%
AVIF 70	65%	66%	82%
AVIF 72	72%	74%	94%
AVIF 74 (proposed for core)	83%	85%	97%
AVIF 76	88%	91%	99%
AVIF 78	92%	95%	99%
AVIF 82 (current default)	97%	99%	100%
WebP 86 (core's WebP default)	73%	72%	75%
WebP 82 (plugin's WebP quality)	39%	34%	40%

File size compared with JPEG 82 (lower is better):

Format and quality	GD	Imagick	Browser
AVIF 66	61%	63%	60%
AVIF 70	65%	67%	70%
AVIF 72	68%	69%	74%
AVIF 74 (proposed for core)	72%	74%	76%
AVIF 76	75%	77%	81%
AVIF 78	79%	81%	84%
AVIF 82 (current default)	91%	93%	93%
WebP 86 (core's WebP default)	83%	84%	84%
WebP 82 (plugin's WebP quality)	70%	72%	72%

Compared with core's own WebP default, AVIF 74 looks as good as JPEG 82 more often (83% to 97% against 72% to 75%) and is smaller (72% to 76% of the JPEG size against 83% to 84%). AVIF 82 adds only a few more matches but its files are 22% to 26% larger than at AVIF 74.

Lowest AVIF quality that looks as good as JPEG 82 (lower means AVIF needs less quality to keep up):

Share of generated images covered	GD	Imagick	Browser
Half	66	68	68
Three in four	74	74	70
Nine in ten	78	76	72

The typical image (half) needs only 66 to 68. A default has to work for most images, though, and 74 covers three in four or more on every editor.

By kind of image. Lowest AVIF quality that looks as good as JPEG 82 for half of the generated images:

Kind	GD	Imagick	Browser
Photos	68	70	68
Diagrams	62	60	60
Screenshots	52	56	56

JPEG handles flat colours and sharp text poorly, so AVIF keeps up with it at a much lower quality on diagrams and screenshots. That is why the median over all images (66 to 68) is lower than for photos. Photos are the hardest case. Large photos (CLIC, 2048 pixels wide) need 72 with GD and 74 with Imagick.

AVIF compared with WebP 82 (the goal for the plugin)

How often AVIF looks at least as good as WebP 82 (higher is better):

Format and quality	GD	Imagick	Browser
AVIF 66	58%	74%	38%
AVIF 68	70%	87%	71%
AVIF 70 (proposed for the plugin)	79%	94%	79%
AVIF 72	82%	95%	88%
AVIF 74	86%	97%	92%
AVIF 82 (current default)	91%	98%	97%

File size compared with WebP 82 (lower is better):

Format and quality	GD	Imagick	Browser
AVIF 66	88%	87%	81%
AVIF 68	91%	90%	91%
AVIF 70 (proposed for the plugin)	94%	93%	93%
AVIF 72	97%	96%	98%
AVIF 74	104%	103%	101%
AVIF 82 (current default)	129%	129%	122%

At 74 and above, AVIF is larger than WebP 82. AVIF 70 is the highest quality that still saves bytes over WebP 82 on every editor. Unlike the JPEG comparison, the result does not depend much on the kind of image (the median is 64 to 72 for photos, diagrams and screenshots).

Newer AVIF libraries

The results above use the AVIF libraries in current Debian and Ubuntu packages. With libaom 3.13 or later, libavif 1.4.0 (used by GD) and libheif 1.22.0 (used by Imagick) switch to a new libaom tuning (tune=iq) with a different quality scale. The browser path already uses it (wasm-vips 0.0.19 ships libheif 1.23.5 and libaom 3.15.1).

To check whether this changes the answer, 73 of the images (all Kodak and plugin images, 30 CID22 images, 6 diagrams, 4 page screenshots and the 5 theme screenshots) were run again on php:8.3-cli-alpine3.24. That image ships libavif 1.4.1, ImageMagick 7.1.2-35 with libheif 1.23.4, and libaom 3.14.1. The same 73 images from the main run are used for the comparison.

AVIF 74 compared with JPEG 82, current and newer libraries:

Editor	Libraries	Looks at least as good as JPEG 82 (higher is better)	File size compared with JPEG 82 (lower is better)
GD	Current (libavif 1.2.1)	83%	72%
GD	Newer (libavif 1.4.1)	98%	82%
Imagick	Current (libheif 1.23.6, libaom 3.12.1)	86%	74%
Imagick	Newer (libheif 1.23.4, libaom 3.14.1)	99%	74%

GD. PHP fixes the compression level for the quality number, and the new tuning spends more bytes on detail at that level. At the same quality number, files are about 7% larger and look better. AVIF 74 is still clearly smaller than JPEG 82, but on these servers a lower quality (median 60) would already match JPEG 82.
Imagick. libheif changes the quality scale together with the tuning, so file sizes stay about the same and AVIF 74 matches JPEG 82 even more often.
Plugin. On the newer libraries AVIF 70 still matches WebP 82 on most images (87% with GD, 86% with Imagick). With GD it is now about 3% larger than WebP 82, while with Imagick it stays 7% smaller.

So 74 stays a safe default with both the current and the newer libraries. The only cost on newer servers is a smaller saving with GD, not lower quality. Very few servers have the newer libraries today: no current Debian or Ubuntu LTS release ships libaom 3.13 together with libavif 1.4 or libheif 1.22.

Proposed fix

Plugin: pin the AVIF quality to 70 in webp_uploads_modify_webp_quality(), next to WebP 82 ( Use an AVIF quality equivalent to the default WebP quality #2746).
Core: add an AVIF default of 74 to WP_Image_Editor::get_default_quality() and wp_get_image_encode_quality(), so sites without the plugin get smaller AVIF files too (Trac ticket to follow).

GD and Imagick turn the quality number into the same compression setting, and the browser reads the same filter, so one value covers all three editors.

Are you okay with different defaults for Core (74) and the plugin (70), given their different WebP quality settings?
I'd suggest keeping Core's WebP 86 unchanged, as increasing it to 90 would bring file sizes close to JPEG 82. Does that sound reasonable?
Should we target WordPress 7.2 before RC1, a 7.2.x release, or 7.3?

The patch and unit tests are ready. It updates both WP_Image_Editor::get_default_quality() and wp_get_image_encode_quality() to cover server-side and browser encoding.

@jakearchibald

@jakearchibald The main run used Debian 13 (libavif 1.2.1, libheif 1.23.6, libaom 3.12.1), which is still on tune=ssim. So I reran 73 of the images on Alpine 3.24 (libavif 1.4.1, libheif 1.23.4, libaom 3.14.1), where both GD and Imagick get tune=iq.

You're right that tune=iq is more stable. This is the gap in SSIMULACRA 2 between AVIF 70 and JPEG 82 on the same image, for the middle 80% of images (10th to 90th percentile):

Editor	`tune=ssim` (Debian 13)	`tune=iq` (Alpine 3.24)
GD	-1.1 to +5.8 (6.9 points wide)	+2.7 to +6.7 (4.0 points wide)
Imagick	-1.2 to +4.9 (6.1 points wide)	+0.8 to +4.7 (3.8 points wide)

The range is almost half as wide, and the low end moves from "a bit worse than JPEG" to "better than JPEG". The browser side (wasm-vips, which already uses tune=iq) shows the same narrow range on these images: +1.0 to +4.6.

At the proposed core default of 74:

Editor	Libraries	Average SSIMULACRA 2 gap vs JPEG 82	Generated images at least as good as JPEG 82	Size vs JPEG 82
GD	Debian 13	+3.6	83%	72%
GD	Alpine 3.24	+5.5	98%	82%
Imagick	Debian 13	+3.2	86%	74%
Imagick	Alpine 3.24	+3.6	99%	74%

"Generated images" counts every size WordPress generates (thumbnail, medium, large and so on). "At least as good" means SSIMULACRA 2, Butteraugli and DSSIM all score the AVIF no worse than the JPEG 82 version of the same size.

On average, AVIF already matches JPEG 82 at around 64 to 66. The default is set higher so that nearly every image matches, not just the average one. With tune=iq that takes much less margin.

One WordPress-specific catch: GD passes a fixed quantizer to libavif, not a quality value. So it keeps the old quality scale and only gets the better tuning, which is why its files at 74 are larger on Alpine (82% vs 72% of JPEG). Imagick gets the new scale through libheif, so its sizes stay the same.

About quality 50: WordPress serves every generated size, down to small thumbnails, and many are shown at 1x. The goal here is also to match WordPress's own JPEG 82 default. On these images, Imagick with tune=iq is already 2.4 points below JPEG 82 on average at quality 60.

The full numbers and scripts are in https://b1ink0.github.io/avif-quality-benchmark/.

@jakearchibald

https://jakearchibald.com/2026/jpeg-xl-vs-avif/#quality-stability here's some stuff I did on quality numbers, but I didn't look at WebP.

Thanks for stopping by and lending your overqualified expertise @jakearchibald - I guess you just appear whenever someone mentions image quality three times in a row :)

@b1ink0 Thanks for the additional research, here are some answers to your questions at the end:

Before I open the Core ticket, I'd like your thoughts on three things:

Are you okay with different defaults for Core (74) and the plugin (70), given their different WebP quality settings?

Thats fine, the plugin is experimentation, so lets push the quality a little lower here.

I'd suggest keeping Core's WebP 86 unchanged, as increasing it to 90 would bring file sizes close to JPEG 82. Does that sound reasonable?

If anything I would want to lower the quality of WebPs so lets leave it unchanged for now.

Should we target WordPress 7.2 before RC1, a 7.2.x release, or 7.3?

7.3 - its probably too late in the 7.2 cycle for these types of changes.

ps. nice to see the browser based processing with wasm-vips doing the best job overall, and we'll be able to ship new versions of packages with WordPress releases now since we no longer depend on what version of the libraries the server supports. Since we added client-side handling for the media library and both Safari and Firefox are working on DIP implementation (which the feature requires) I expect most WordPress image handling will use the client-side path going forward. Given that, I would use the browser path as your expected stack and work based on those numbers.

Thanks for stopping by and lending your overqualified expertise @jakearchibald - I guess you just appear whenever someone mentions image quality three times in a row :)

It is my curse. I supposed to be on holiday too haha

Thanks for stopping by and lending your overqualified expertise @jakearchibald - I guess you just appear whenever someone mentions image quality three times in a row :)

It is my curse. I supposed to be on holiday too haha

Hope you have a nice vacation and see you over on the JPEG XL ticket ;)

Add JPEG XL support gutenberg#77584

Navigation Menu

Repository navigation

AVIF sub-sizes are larger than WebP at the default quality of 82 #2745

Bug Description

Steps to reproduce

Result

Cause

Which AVIF quality to use

Short answer

How it was tested

How to read the tables

AVIF compared with JPEG 82 (the goal for core)

AVIF compared with WebP 82 (the goal for the plugin)

Newer AVIF libraries

Proposed fix

Related

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

AVIF sub-sizes are larger than WebP at the default quality of 82 #2745

Description

Bug Description

Steps to reproduce

Result

Cause

Which AVIF quality to use

Short answer

How it was tested

How to read the tables

AVIF compared with JPEG 82 (the goal for core)

AVIF compared with WebP 82 (the goal for the plugin)

Newer AVIF libraries

Proposed fix

Related

Activity

b1ink0 commented on Nov 3, 2026

b1ink0 commented on Nov 4, 2026

adamsilverstein commented on Nov 6, 2026

b1ink0 commented on Nov 6, 2026

jakearchibald commented on Nov 6, 2026

b1ink0 commented on Nov 6, 2026

jakearchibald commented on Nov 6, 2026

jakearchibald commented on Nov 6, 2026

b1ink0 commented on Nov 6, 2026

b1ink0 commented on Nov 6, 2026

adamsilverstein commented on Nov 6, 2026

adamsilverstein commented on Nov 6, 2026

jakearchibald commented on Nov 6, 2026

adamsilverstein commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions