AVIF vs. WebP in a CMS: Why WebP Is the Better Choice

15 July 2026

Every CMS, Joomla, WordPress, Drupal, or anything else that lets users upload images through an admin panel, eventually has to answer the same question: which modern image format should it use to generate thumbnails and web sized images. AVIF and WebP are the two candidates on the table, and AVIF often gets pitched as the future because it can compress harder than WebP on paper. When it comes to a CMS that generates images on its own server, that promise doesn't hold up well in practice. Based on the evidence below, WebP looks like the more practical choice for CMS generated images today, while AVIF is not yet worth building into a default image pipeline.

AVIF comes from a video codec

AVIF isn't a format designed from scratch for still images. It's a still frame container built on top of AV1, a video compression codec developed for streaming video. That heritage matters, because video codecs are built and tuned around a specific workflow: encode once, offline, on dedicated hardware or heavy server infrastructure, and decode billions of times afterward on cheap client devices. That trade off makes sense for a streaming platform, where content is encoded once and served forever.

A CMS works differently. It needs to encode images on an ongoing basis, on the server, at the time a user uploads a photo, or whenever a theme changes a thumbnail size, or when a gallery gets rebuilt. Applying a video codec's still image mode to that kind of workflow means paying video-encoding style costs on every single upload, on whatever shared or mid tier hosting the site happens to run on. That mismatch is worth keeping in mind when comparing the two formats for CMS use.

What testing shows

When generating images on the server using the GD library at 100% quality, the following was measured across formats:

Two things stand out here. First, at default encoder settings, AVIF didn't even beat WebP on file size. The compression advantage AVIF is known for only shows up once the encoder effort is turned way up, since that's how a video codec finds extra savings: by spending much more compute searching for redundancy. Second, turning that effort up moved generation time from a fraction of a second to 46.7 seconds for a single image. For a gallery with hundreds of photos, or a CMS that regenerates thumbnails whenever a template or size setting changes, that kind of cost adds up quickly and can turn into hours of server time, or a request that simply times out.

This lines up with what broader image format benchmarking reports in 2026: AVIF encoding is commonly measured at somewhere between 5 and 50 times slower than WebP, and can add several seconds, sometimes considerably more, per image during upload processing. It's part of why performance focused CDNs tend to run AVIF encoding as a background job rather than doing it inside a live request. A CDN can be built around that kind of infrastructure. A typical CMS install on shared hosting usually isn't.

Why this matters more inside a CMS

A generic AVIF vs WebP comparison often assumes a build pipeline: images are converted once, pushed to a CDN, and never touched again. A CMS doesn't usually work that way, and several practical points follow from that:

• Thumbnails get regenerated often. Changing a gallery layout, a theme, a crop setting, or a plugin's image dimensions in Joomla, WordPress, or Drupal typically rebuilds every existing thumbnail. A slower, video grade encoder multiplied across a large media library adds up.
• Generating images on first visitor request becomes riskier with AVIF. Some setups generate a thumbnail the first time a visitor requests it rather than ahead of time in the admin backend. That's already a debatable approach for performance reasons in general, and with AVIF it means a visitor can end up waiting on a multi second, or at higher compression a multi minute, encode.
• Server library support is inconsistent. Both GD and ImageMagick can have trouble with AVIF. GD builds sometimes ship with mismatched or missing AVIF dependencies, and ImageMagick needs version 7, while a number of Linux distributions still default to the older version 6. On shared or budget hosting, where a large share of Joomla, WordPress, and Drupal sites run, that's a real, recurring issue rather than a hypothetical one.
• Failures aren't always visible. When the required library is missing or misconfigured, some setups don't fail loudly. A file can end up with an .avif extension while internally still being PNG or another format. That kind of quiet mismatch is harder to catch during testing than an image that's obviously broken.
• Serving it safely tends to need extra infrastructure. Because AVIF still needs a fallback for browsers and tools that can't decode it, using it well generally means generating and storing multiple variants of every image, keeping them in sync, and adding markup overhead through a picture element. That fallback setup also only covers img and picture markup that's directly controlled. Background images in CSS, images injected by third party widgets, RSS feeds, and email templates don't benefit from it and still need a conventional format regardless. In practice this means AVIF adds extra plumbing on top of a fallback format like WebP, rather than replacing the need for one.

None of this is meant as a broad dismissal of AVIF as a technology. It's simply what tends to happen when a codec built for offline video encoding is applied to a live, per upload image pipeline running on ordinary web hosting.

Where WebP compares favourably

WebP was designed from the start as a web image format rather than adapted from a video codec, and that shows up in how it behaves in the tests above and in general use: encoding stays fast and fairly predictable regardless of how the compression settings are pushed, support in GD, ImageMagick, and CMS plugin ecosystems is broad and mature, transparency is supported well enough to replace PNG, animation is supported well enough to replace GIF, and browser support sits around 97% or more of global traffic, largely stable since Safari added support in 2020. There's no equivalent to AVIF's silent mismatch failure mode, no need to check whether a given host's ImageMagick build is new enough, and no realistic scenario where uploading a single photo holds up a request for tens of seconds.

Practical takeaway for CMS defaults

Whether it's Joomla, WordPress, or Drupal, the evidence points in the same direction:

1. WebP is a reasonable default format for thumbnails and resized images generated by a CMS. It replaces PNG well (keeps transparency, meaningfully smaller) and replaces JPEG well for most photography, while encoding fast and working broadly without extra plumbing.
2. AVIF isn't yet a good fit for a default image pipeline. The encoding cost, the inconsistent server side library support, and the extra fallback infrastructure it tends to require outweigh the compression gain for a system that generates images live, on hosting that isn't always fully controlled.
3. Generating thumbnails only on first visitor request is worth avoiding in general, and especially so with a format that carries video encoding style costs.

In summary

AVIF's compression numbers look strong in isolation, but they come from a codec built for a different workflow: encode once offline, decode indefinitely afterward. A CMS operates closer to the opposite pattern, encoding on an ongoing basis, live, on hosting environments that vary a lot in what they support. That difference is a large part of why AVIF runs into slow encoding, inconsistent server library support, and quiet failures in exactly the setting a CMS operates in, while WebP, built with the web in mind from the outset, tends to just work. Based on the current evidence, WebP is the more practical choice for CMS generated images.