Is AVIF better than WebP for WordPress images?

AVIF can produce smaller image files than WebP at comparable visual quality, but that does not automatically make AVIF the better format for every WordPress image.

The real answer depends on what you are optimizing for.

You need to consider:

• image quality;
• file size;
• browser compatibility;
• WordPress support;
• server image-processing support;
• encoding and decoding cost;
• transparency;
• animation;
• HDR and color depth;
• responsive image generation;
• CDN behavior;
• your existing media workflow.

For many photographs, AVIF can achieve excellent visual quality at a lower file size than WebP. WebP, however, remains an extremely efficient format with a longer deployment history, broad browser support and mature tooling.

The practical answer is therefore:

AVIF is often more compression-efficient, but WebP is still an excellent WordPress image format.

This guide compares AVIF and WebP specifically for WordPress, including current WordPress 7.1 image processing, hosting requirements, browser support, Core Web Vitals, transparency, responsive images and real production workflows.

AVIF vs. WebP: the short answer

If you need a starting point:

• Choose AVIF when minimizing photographic image weight is a high priority and your WordPress processing and delivery stack supports it reliably.
• Choose WebP when you want excellent compression with a very mature and broadly compatible workflow.
• Compare the real files instead of assuming one codec wins for every image.
• Optimize dimensions before obsessing over format, because an oversized AVIF can still waste more bandwidth than a correctly sized WebP.

For a broader comparison that also includes JPEG, see WebP vs. AVIF vs. JPEG for WordPress.

What is WebP?

WebP is a modern raster image format originally developed by Google for efficient web delivery.

It supports:

• lossy compression;
• lossless compression;
• alpha transparency;
• animation;
• higher color depth than traditional JPEG workflows.

The MDN image format guide describes WebP as an excellent choice for both still and animated images, with substantially better compression than traditional formats such as JPEG and PNG for many web use cases.

WordPress has supported WebP since version 5.8

WordPress added native WebP support in version 5.8.

The official WordPress 5.8 WebP developer note explains that WebP images can be uploaded and used like JPEG or PNG images when the hosting environment provides the required image-processing support.

That means WordPress can work with WebP in normal Media Library workflows, including generated image sub-sizes where supported.

WebP has therefore been part of WordPress Core for several major release cycles and has a mature ecosystem around it.

What is AVIF?

AVIF stands for AV1 Image File Format.

It stores image data using technology based on the AV1 codec inside the AVIF container format.

AVIF supports:

• lossy compression;
• lossless compression;
• alpha transparency;
• animation;
• 8-bit, 10-bit and 12-bit image data;
• wide color gamut;
• HDR imagery.

The MDN image format documentation notes that AVIF generally achieves stronger compression than WebP while supporting advanced features including transparency, animation, HDR and wide color gamuts.

WordPress added AVIF support in version 6.5

WordPress introduced native AVIF support in version 6.5.

The official WordPress 6.5 AVIF developer note explains that users can upload and use AVIF images similarly to JPEG and PNG when the hosting environment supports AVIF processing.

This distinction matters:

WordPress understands AVIF
+
server can process AVIF
=
complete traditional WordPress AVIF workflow

Historically, the second part depended heavily on GD, Imagick and the codec libraries available on the host.

WordPress 7.1 changes how image processing works

WordPress 7.1 introduced one of the biggest changes to WordPress image processing in years.

Where supported, image processing can now happen in the user’s browser before generated derivatives are uploaded to the server.

The official WordPress client-side media processing documentation explains that WordPress uses libvips through WebAssembly to handle operations including:

• image resizing;
• compression;
• format conversion;
• rotation;
• thumbnail generation.

Why this matters for AVIF

Before this architecture, AVIF processing could be limited by whatever image libraries the hosting provider happened to install.

WordPress 7.1 can provide a more consistent processing environment on supported devices because modern image processing can happen client-side.

This also reduces pressure on:

• PHP memory;
• server CPU;
• PHP execution time;
• shared hosting resources.

If client-side processing is unavailable, WordPress transparently falls back to the traditional server-side path.

This means hosting support has not magically ceased to exist as a consideration. It simply matters less often when the browser-side pipeline can take over.

For the wider thumbnail pipeline, see How WordPress Generates Image Thumbnails.

Does AVIF produce smaller files than WebP?

Frequently, yes.

AVIF is capable of very strong lossy compression and commonly produces smaller files than WebP at similar perceived image quality, especially for photographic content.

MDN’s comparison describes AVIF as generally offering better compression than WebP, although the exact advantage depends on the source and encoding settings.

There is no reliable universal rule such as:

AVIF is always 30% smaller than WebP

because real results depend on several variables.

The source image matters

Compression behaves differently for:

• photographs;
• product images;
• screenshots;
• flat graphics;
• gradients;
• text-heavy graphics;
• transparent images.

A codec that performs exceptionally well on photography may produce a smaller advantage on a UI screenshot.

The encoder matters

Results can vary according to:

• encoder implementation;
• encoding effort;
• quality setting;
• chroma configuration;
• bit depth;
• metadata handling.

Quality numbers cannot be compared directly

An AVIF encoded at:

quality 75

does not necessarily represent the same visual quality as:

WebP quality 75

or:

JPEG quality 75

The scales belong to different codecs and implementations.

The useful comparison is:

similar perceived visual quality
↓
compare resulting file size

Image dimensions can matter more than format

Choosing AVIF cannot compensate for delivering absurdly oversized images.

Suppose a WordPress layout displays an image at roughly:

800 × 600 pixels

but the visitor downloads:

4800 × 3600 pixels

Converting that resource from WebP to AVIF may reduce transfer size, but you are still sending far more pixel data than the layout requires.

WordPress responsive images are critical

WordPress generates multiple image sizes and can expose them through HTML attributes such as:

srcset
sizes

The browser can then select a more appropriate resource for its viewport and display density.

For the underlying mechanism, read How WordPress Generates Image Sizes.

A correctly selected 640-pixel WebP can easily be more efficient than downloading a 1600-pixel AVIF that the screen does not need.

AVIF vs. WebP image quality

Both formats can produce excellent web images.

The objective should not be:

smallest file at any cost

It should be:

smallest practical file
that still satisfies visual requirements

Where AVIF often performs especially well

AVIF is particularly strong for content containing:

• photographic detail;
• skin tones;
• gradients;
• natural textures;
• complex lighting;
• large smooth areas.

It can often retain convincing visual quality at lower bitrates than older image formats.

AVIF can still look bad

A more sophisticated codec cannot repeal compression artifacts.

At aggressive settings, AVIF can still produce:

• lost texture;
• smearing;
• edge degradation;
• color changes;
• lost fine detail;
• visible compression artifacts.

A tiny image that visibly damages the content is not optimized. It is merely tiny.

WebP is still highly efficient

It is easy to discuss AVIF as though WebP suddenly became a primitive format. It did not.

The official WordPress WebP documentation notes that WebP can deliver substantial savings compared with traditional JPEG and PNG workflows.

For many WordPress sites, moving from:

unoptimized JPEG

to:

properly sized WebP

can deliver a much larger real-world improvement than moving from an already optimized WebP to AVIF.

AVIF should therefore be evaluated as an additional optimization opportunity, not as proof that every WebP needs immediate replacement.

Browser support for AVIF and WebP

Both WebP and AVIF are supported across current major browsers.

WebP has the advantage of a longer history of browser adoption.

AVIF support arrived later but is now available in modern Chrome, Edge, Firefox, Safari and other current browser engines.

The MDN browser image-format reference provides current compatibility information for both formats.

Do you still need fallbacks?

That depends on your audience rather than a generic recommendation.

Review:

• browser analytics;
• operating systems;
• embedded webviews;
• special enterprise environments;
• older devices that matter to your business.

For a normal modern consumer website, AVIF compatibility is far less problematic than it once was.

Using the picture element for format fallbacks

HTML provides the <picture> element for offering alternative image sources.

MDN specifically documents the picture element as a way to offer different image formats when browser support differs.

For example:

<picture>
    <source
        srcset="photo.avif"
        type="image/avif"
    >
    <source
        srcset="photo.webp"
        type="image/webp"
    >
    <img
        src="photo.jpg"
        alt="Example photograph"
        width="1200"
        height="800"
    >
</picture>

The browser can work through the available candidates and use a format it supports.

This can create a delivery hierarchy such as:

AVIF
↓
WebP
↓
JPEG

Whether you need this complexity depends on your compatibility requirements and CDN or optimization architecture.

Transparency: AVIF vs. WebP

Both AVIF and WebP support alpha transparency.

That means either may replace PNG for certain raster assets such as:

• product cutouts;
• photographic overlays;
• complex graphics with transparent regions;
• decorative raster elements.

Do not automatically convert every PNG

PNG remains useful when:

• exact lossless reproduction matters;
• the source is already tiny;
• your workflow specifically requires PNG;
• the asset is used outside modern browser environments.

For logos, icons and geometric illustrations, SVG may be more suitable than any raster format.

AVIF has stronger HDR and color capabilities

AVIF supports advanced imaging features including:

• 10-bit and 12-bit color depths;
• HDR;
• wide color gamut;
• alpha transparency.

These capabilities are documented in the MDN AVIF format reference.

This makes AVIF particularly interesting for modern photographic workflows.

However, those capabilities matter only if the full pipeline preserves them.

An HDR source converted to ordinary SDR somewhere between the image editor, WordPress, optimization plugin and CDN will obviously stop being HDR, because software remains stubbornly committed to cause and effect.

What about animated AVIF and WebP?

Both formats can support animation.

But format-level support and WordPress image-processing support are not necessarily the same thing.

Resizing or converting an animated resource may behave differently depending on:

• WordPress version;
• browser-side processing;
• GD or Imagick configuration;
• plugins;
• CDN transformation rules.

If animation matters, test the complete upload, resize and frontend delivery workflow rather than relying only on the format specification.

AVIF encoding can require more processing

AVIF can require more encoding work than simpler image formats, especially at more computationally intensive encoder settings.

This becomes important when WordPress generates several derivatives from one upload.

A single image may produce:

• thumbnail;
• medium;
• medium-large;
• large;
• theme-defined sizes;
• plugin-defined sizes;
• WooCommerce-specific sizes.

One upload can therefore trigger several encode operations.

WordPress 7.1 reduces server-side pressure

The new client-side media architecture can move much of this work away from PHP where supported.

WordPress documents benefits including:

• lower server load;
• fewer PHP memory-limit problems;
• more consistent image processing;
• modern format support through the browser-side processing pipeline.

You can read the technical architecture in the official Client-Side Media Processing documentation.

Check whether your server can process AVIF

When WordPress falls back to traditional server-side image processing, AVIF support still depends on the server’s available libraries.

Traditionally WordPress uses image editors backed by technologies such as:

• Imagick/ImageMagick;
• GD.

The official WordPress AVIF developer note recommends checking the site’s media capabilities when determining whether AVIF is supported by the hosting environment.

Do not test support only by opening an AVIF URL

These are different capabilities:

web server can serve an AVIF file

and:

WordPress image editor can decode,
resize and encode AVIF

A successful browser request proves only the first.

Test:

• uploading;
• resizing;
• thumbnail creation;
• cropping;
• format conversion.

WordPress does not automatically convert everything to AVIF

Native AVIF support does not mean that uploading a JPEG automatically turns all generated WordPress images into AVIF.

WordPress normally preserves source format unless another output mapping has been configured.

WordPress provides the:

image_editor_output_format

filter for changing image output mappings.

The official image_editor_output_format documentation explains how a source MIME type can be mapped to another output format.

Example: generate AVIF derivatives from JPEG uploads

add_filter( 'image_editor_output_format', function( $formats ) {
    $formats['image/jpeg'] = 'image/avif';

    return $formats;
} );

This tells compatible WordPress image-processing operations to use AVIF as the mapped output for JPEG sources.

Do not deploy a global conversion rule without testing:

• server support;
• browser-side processing;
• theme compatibility;
• plugins;
• CDN behavior;
• image quality.

Conversion is not the same as optimization

Changing:

.jpg
→
.avif

does not guarantee a well-optimized image.

Final image weight still depends on:

• dimensions;
• quality;
• encoder settings;
• metadata;
• source complexity;
• generated image sizes.

An unnecessarily huge AVIF is still unnecessarily huge.

Avoid repeated lossy transcoding

Both AVIF and WebP can use lossy compression.

Lossy compression discards image information.

A poor media workflow might repeatedly convert:

JPEG
↓
WebP
↓
AVIF
↓
recompressed AVIF

Each lossy generation can introduce additional degradation.

Keep a suitable master image

A healthier workflow is:

high-quality source
↓
generate optimized delivery versions

This allows future derivatives to be generated from a better source rather than from another already compressed output.

AVIF vs. WebP for photographs

Photography is one of the strongest use cases for AVIF.

That includes:

• hero images;
• editorial photography;
• travel images;
• large portfolio photography;
• background images;
• product lifestyle imagery.

If an AVIF version is meaningfully smaller at visually equivalent quality, it can reduce page transfer size without requiring layout changes.

AVIF vs. WebP for e-commerce product images

E-commerce requires more caution because image quality affects product perception.

Inspect details such as:

• fabric texture;
• jewelry edges;
• metallic reflections;
• small labels;
• skin tones;
• surface texture;
• zoomed product details.

Do not select compression purely from an automated file-size score.

A 40% saving is rather less exciting when the product starts looking 40% cheaper too.

AVIF vs. WebP for screenshots

Screenshots contain a different visual structure from photographs.

They often include:

• small text;
• sharp lines;
• flat backgrounds;
• UI controls;
• icons;
• high-contrast edges.

Test several candidates rather than assuming AVIF wins.

Useful comparisons may include:

• AVIF;
• lossy WebP;
• lossless WebP;
• PNG.

Does AVIF improve Core Web Vitals?

AVIF can improve performance when it materially reduces the amount of data required to display important images.

It is especially relevant when the image is the page’s Largest Contentful Paint candidate.

However, Core Web Vitals do not award points based on image extension.

For the complete relationship between image weight and CWV, see Core Web Vitals and Image Weight.

AVIF does not automatically fix LCP

An AVIF hero can still have poor LCP when:

• it is incorrectly lazy-loaded;
• the resource is discovered late;
• JavaScript inserts it after initial rendering;
• the server is slow;
• the image is oversized;
• responsive markup selects the wrong candidate;
• other high-priority resources compete with it.

AVIF does not fix CLS

Cumulative Layout Shift is about unexpected movement.

An AVIF without reserved layout dimensions can still shift content.

Correct width, height, aspect ratio and CSS remain necessary.

Responsive delivery remains more important than codec worship

The browser should receive an image appropriate to the current layout.

For example:

mobile viewport
→ smaller image candidate

large desktop viewport
→ larger image candidate

Responsive images and modern formats solve different problems.

Use both.

What happens to existing WordPress images?

Changing your preferred output format does not normally rebuild every historical attachment automatically.

Your Media Library can therefore contain a mixture of:

• JPEG;
• PNG;
• WebP;
• AVIF;
• derivatives created under older settings.

You may need to regenerate thumbnails

If you change your image-generation strategy and want existing attachments to receive new derivatives, thumbnail regeneration may be necessary.

Read Regenerating WordPress Image Thumbnails before performing a large migration.

Regeneration can affect:

• CPU usage;
• storage;
• backup size;
• CDN caches;
• deployment time.

Do not delete original images too aggressively

Keeping a high-quality source can be valuable if you later need to:

• switch formats;
• change quality;
• create new image sizes;
• move to another CDN;
• adopt a newer encoder.

You cannot recover detail that has already been discarded by a lossy derivative.

AVIF, WebP and CDNs

Modern image CDNs can often dynamically transform a source image according to browser capabilities.

A CDN may:

• store the original source;
• generate AVIF dynamically;
• generate WebP dynamically;
• select format from request headers;
• resize by viewport requirements;
• apply its own quality settings.

Avoid duplicate optimization layers

A complicated WordPress image pipeline might accidentally do this:

WordPress converts JPEG to AVIF
↓
plugin recompresses AVIF
↓
CDN recompresses image again

This can add processing and reduce quality without producing a meaningful benefit.

Choose which layer owns final delivery optimization.

Should you convert your entire Media Library to AVIF?

Not simply because AVIF is newer.

Before running a site-wide migration, measure:

• current image transfer size;
• existing WebP efficiency;
• expected AVIF savings;
• processing time;
• storage implications;
• CDN behavior;
• browser requirements.

Optimize the largest opportunities first

Prioritize:

• large hero images;
• high-traffic landing pages;
• large product galleries;
• popular article images;
• background photography.

Reducing a 900 KB hero to 180 KB matters far more than spending an afternoon turning a 9 KB thumbnail into a heroic 7 KB thumbnail.

How to compare AVIF and WebP correctly

Start from the same source

Do not compare an AVIF converted from a high-quality master with a WebP generated from an already compressed JPEG.

Match visual quality

Adjust encoding parameters until the two images are visually comparable.

Compare final bytes

Then compare their actual transferred file sizes.

Inspect difficult image areas

Look closely at:

• hair;
• fabric;
• fine text;
• gradients;
• shadows;
• skin;
• sharp edges;
• small product details.

Test inside the real page

Measure:

• network transfer;
• image discovery time;
• LCP where relevant;
• responsive candidate selection;
• mobile performance.

When AVIF is probably the better choice

AVIF is particularly compelling when:

• your site uses large photographs;
• file size is a major performance concern;
• your users rely primarily on modern browsers;
• your WordPress processing pipeline supports AVIF reliably;
• your CDN supports the format;
• you can verify image quality;
• HDR or higher bit depths are valuable.

When WebP may still be the better choice

WebP can remain preferable when:

• your existing WebP workflow already performs extremely well;
• you need a longer historical compatibility range;
• your hosting tools have stronger WebP support;
• third-party integrations do not handle AVIF reliably;
• the AVIF savings are too small to justify migration complexity;
• workflow simplicity matters more than marginal compression gains.

How TheOneWP can help

Image Optimizer

Image Optimizer lets you optimize WordPress images and select supported output formats including:

• JPEG;
• PNG;
• WebP;
• AVIF.

The interface can indicate WebP and AVIF support in the current environment and provides image information, resolution controls, quality controls and estimated output-size information.

This makes it possible to compare formats according to the actual image rather than applying one codec to everything indiscriminately.

Image Sizes List

Image Sizes List helps inspect the image dimensions registered by WordPress, themes and plugins.

This is useful because eliminating unnecessary image sizes can sometimes produce a larger operational improvement than changing formats.

AVIF vs. WebP WordPress checklist

• WordPress has supported WebP since version 5.8.
• WordPress has supported AVIF since version 6.5.
• WordPress 7.1 introduces client-side media processing where supported.
• AVIF often compresses photographic content more efficiently.
• WebP remains a highly efficient modern format.
• Do not compare identical codec quality numbers.
• Compare visually equivalent outputs.
• Correct image dimensions remain essential.
• Use responsive images.
• Both AVIF and WebP support transparency.
• Both can support animation.
• AVIF supports high bit depth, wide gamut and HDR.
• Check server support for fallback processing.
• Do not assume serving an AVIF proves the server can encode AVIF.
• Use image_editor_output_format carefully when changing derivative formats.
• Do not repeatedly transcode lossy delivery files.
• Keep suitable master images.
• Check CDN transformation behavior.
• Avoid duplicate optimization layers.
• Measure important images on real pages.
• Choose the best result, not simply the newest format.

Related guides

• WebP vs. AVIF vs. JPEG for WordPress
• Core Web Vitals and Image Weight
• How WordPress Generates Image Thumbnails
• How WordPress Generates Image Sizes
• Regenerating WordPress Image Thumbnails
• Finding a Specific WordPress Image Size URL
• Replacing vs. Re-uploading WordPress Media
• WordPress Image Cache Busting Explained

Final thoughts

AVIF is often capable of producing smaller files than WebP at comparable visual quality, particularly for photographic content.

That makes it one of the strongest image formats available to modern WordPress sites.

But newer does not automatically mean better for every image or every workflow.

WebP already offers excellent compression, transparency, animation, broad compatibility and mature WordPress support.

The useful question is not:

Is AVIF technically better than WebP?

It is:

Which format gives this image
the required visual quality
at the lowest practical delivery cost
for this WordPress site?

Start by fixing dimensions and responsive image delivery.

Then compare AVIF and WebP generated from the same high-quality source.

Inspect visual quality, transferred bytes, browser compatibility and the complete WordPress-to-CDN-to-browser pipeline.

If AVIF provides a meaningful saving while preserving quality and workflow reliability, use it.

If an optimized WebP is already small, visually excellent and universally reliable for your target audience, there is no compelling reason to replace it purely because AVIF wins a specification comparison.

The best format is the one that delivers the right image with the least unnecessary data, processing and complexity.