Getting Real AVIF Delivery Out of WordPress

WordPress understands AVIF natively since version 6.5, yet most sites still ship JPEG to visitors. This guide closes that gap: what core actually does, where it stops, and the smallest path to real AVIF delivery.

For the format itself, see AVIF. For the fallback tier, see WebP. For why AVIF beats both, see AVIF vs WebP.

What WordPress core does with AVIF

WordPress 6.5, released 2 April 2024, treats .avif as a first-class image type. Three behaviours come built in:

Uploads — the Media Library accepts .avif files like JPEG or PNG.
Serving — an uploaded AVIF is delivered as image/avif with no conversion step.
Size variants — core generates thumbnail, medium, large, and full sizes from an AVIF original, and wires them into srcset, fetchpriority, and lazy loading.

The Make WordPress Core announcement documents the feature in full. One server prerequisite applies, covered next.

The server requirement you must check first

AVIF in WordPress depends on the image library your host compiled, not on WordPress alone. Core needs one of two backends:

Imagick built against a libheif/libavif-enabled ImageMagick, or
GD compiled with AVIF support, which requires PHP 8.1 or newer.

Check support in Tools → Site Health → Info → Media Handling; it lists the active library and its formats. Without an AVIF-capable backend, uploads still store the file but resizing fails. Ask your host to confirm libheif or a recent ImageMagick is present.

What core does NOT do

Native support handles AVIF files you upload — it never creates them for you. Core deliberately leaves three jobs undone:

It does not auto-convert your existing JPEG and PNG uploads to AVIF.
It does not generate AVIF alternates for new JPEG or PNG uploads.
It does not serve AVIF to capable browsers while falling back to JPEG for the rest.

So uploading AVIF by hand works, but a media library of legacy JPEGs gains nothing automatically. Closing that gap needs a plugin or a CDN, described below.

Plugin options that fill the gap

Four plugins handle bulk conversion and modern-format serving. Each works differently:

ShortPixel Image Optimizer — cloud encoder; converts JPEG/PNG to AVIF on upload and in bulk, then serves via <picture> rewriting or .htaccess rules. Metered per image.
Imagify — cloud encoder from the WP Rocket team; rated strongest for AVIF compression in 2026 plugin tests. Integrates cleanly with WP Rocket caching.
EWWW Image Optimizer — converts locally on your own server with no per-image credits, so a large library costs nothing but CPU time and minutes.
Converter for Media — focused purely on next-gen conversion; rewrites delivery so requests for a JPEG return an AVIF via server rules, with the original kept on disk.

A 2026 round-up by Duplicator compares pricing and output quality across these. Pick on processing location (local vs cloud) and pricing model.

Skipping plugins with CDN-level conversion

An image CDN can convert to AVIF at the edge using the request's Accept header, with zero plugins. Cloudflare Polish, BunnyCDN's Bunny Optimizer, Cloudinary, and Vercel all read Accept: image/avif, then return AVIF to capable browsers and the original to the rest.

Advantages over a plugin:

No conversion delay on upload — the edge encodes on first request, then caches.
No extra .avif files multiplying inside /wp-content/uploads/.
One origin file, many negotiated outputs.

The cost is a hard dependency on the CDN: drop the service and conversion stops. For sites already behind a CDN, this is the least-effort route.

The slow-encode caveat

AVIF encoding is 5–20× slower than WebP at matched effort, which reshapes how you convert at scale. A single 1500×1000 photo can take several seconds on a CPU encoder, so bulk-converting thousands pegs a shared host for hours.

Three practical mitigations:

Local plugins (EWWW) — throttle batch size and run conversions overnight.
Cloud plugins (ShortPixel, Imagify) — push the CPU load off your server entirely.
CDN encoding — amortise cost by encoding lazily on first request, then caching.

See AVIF Compression Settings for the speed-versus-size parameters behind this trade-off.

A serving config you can paste

On Apache, content-negotiation rules return an AVIF when the browser advertises support, keeping a single URL. Add this to .htaccess, with the matching .avif files sitting beside each original:

<IfModule mod_rewrite.c>
  RewriteEngine On
  # Serve image.jpg.avif when the browser accepts AVIF and the file exists
  RewriteCond %{HTTP_ACCEPT} image/avif
  RewriteCond %{REQUEST_FILENAME}.avif -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,E=accept:1,L]
</IfModule>

<IfModule mod_headers.c>
  # Tell caches the response varies by Accept, or old browsers get AVIF
  Header append Vary Accept env=REDIRECT_accept
</IfModule>

The Vary: Accept header is mandatory. Without it, a CDN or proxy can cache the AVIF and hand it to a browser that cannot decode it. Most plugins write rules like these for you.

Verifying AVIF is actually served

Trust the response, not the plugin dashboard — confirm the bytes on the wire are AVIF. Three checks, in order of confidence:

DevTools Network panel — open a page in Chrome, filter to Img, click a request, and read the response Content-Type. It must say image/avif.
Lighthouse — the Serve images in next-gen formats audit should stop flagging. Note Lighthouse fetches once and may not send image/avif, so trust DevTools over it.
Search Console — after a week of traffic, watch LCP in the Core Web Vitals report. See Core Web Vitals & Images.

If Content-Type still reads image/jpeg, the cache is stale or the rewrite never applied. Purge the cache and re-check.

Recommended setup by site type

The right stack depends on where your CPU and your CDN already live. Match your situation:

New site, no CDN — install EWWW Image Optimizer, convert locally to AVIF with a WebP and JPEG fallback, set lossy quality near 50.
Established site, large legacy library — use ShortPixel or Imagify cloud encoding so bulk conversion never stalls your host.
Already behind Cloudflare or another image CDN — skip plugins, enable edge AVIF conversion, and verify the Accept-negotiated response.
WP Rocket user — pair it with Imagify for caching and conversion from one vendor.

For the quality number behind "near 50", see Lossy vs Lossless and AVIF Optimization.

FAQ

Does WordPress convert my old JPEGs to AVIF automatically?

No. Core serves AVIF files you upload but never converts existing JPEG or PNG. A bulk-conversion plugin or a CDN is required.

What WordPress version do I need for AVIF?

Version 6.5 or newer, released 2 April 2024. The host must also run an AVIF-capable Imagick or GD with PHP 8.1+.

Should I upload AVIF directly or let a plugin convert?

Let a plugin or CDN convert. Direct AVIF uploads skip the JPEG fallback, so older browsers in the ~6% without AVIF get nothing. See AVIF Browser Support.

Is AVIF or WebP better for WordPress?

AVIF compresses roughly 20–25% smaller than WebP at matched quality, so AVIF-first with a WebP fallback is ideal. The full comparison is in AVIF vs WebP and AVIF vs JPG.

Convert images to AVIF now

Need an AVIF without installing anything? These tools run entirely in your browser: