WebP, AVIF, and WordPress in 2026: The Image Format Decision

April 19, 2026

The image-format question used to be easy: JPEG for photos, PNG for anything with transparency, done. In 2026, it’s not. WebP is in every browser. AVIF is in every browser except Safari on Windows (which nobody admits exists). JPEG-XL almost made it and then Google pulled Chrome support. PNG and JPEG still ship from the vast majority of WordPress sites. What’s the right answer, for a real-world WordPress site, in 2026?

Short version: WebP everywhere. AVIF on top for photos when bandwidth matters. PNG and JPEG as fallbacks only. The rest of this post is the longer version — with the trade-offs, the browser-support numbers, the WordPress tooling that makes it easy, and the OG-image caveat that catches people out.

Format-by-Format Trade-offs

Format	Compression	Transparency	Animation	Browser support	Best for
JPEG	Good	No	No	Universal	Legacy fallback
PNG	Weak (lossless)	Yes	No	Universal	Logos, icons, screenshots with text
WebP	30% smaller than JPEG	Yes	Yes	97%+ (since 2020)	General-purpose replacement for JPEG+PNG
AVIF	50% smaller than JPEG	Yes	Yes	94%+ (Safari since 2023)	Photos, hero images, bandwidth-critical assets
JPEG-XL	60% smaller than JPEG	Yes	Yes	Firefox only	Skip in 2026 — ecosystem stalled

The Core Web Vitals Math

Image size is the dominant LCP factor on image-heavy pages. The math is brutal:

A 1200×800 hero image as PNG: ~680 KB.
Same image as JPEG quality 85: ~220 KB.
Same image as WebP quality 80: ~140 KB.
Same image as AVIF quality 60: ~85 KB.

On a 3G connection (~400 KB/s real throughput), you’re looking at LCP of 1.7s, 0.55s, 0.35s, and 0.21s respectively. The difference between PNG and AVIF is the difference between “failing Core Web Vitals” and “comfortably passing”. See our Core Web Vitals guide for the full picture.

Browser Support Reality Check (April 2026)

WebP — every browser since Safari 14 (2020). Effectively universal.
AVIF — every browser since Safari 16.1 (2023). 94% support in 2026.
JPEG-XL — Firefox only. Chrome dropped support; Safari shipped it and then walked back default-on. Skip.
PNG — universal. Still the right choice for screenshots with text, UI mockups, and any image where lossless matters.
JPEG — universal. Useful only as a <picture> fallback.

Getting WebP Into WordPress

Three ways to make it happen, in order of simplicity:

WordPress Performance Lab plugin. Free, maintained by the WP core team. Enable the “Modern Image Formats” module and new uploads auto-generate WebP versions. The <img srcset> attribute automatically serves WebP to supporting browsers.
ShortPixel, EWWW, or Imagify. Freemium bulk converters. They handle existing library images in addition to new uploads, and add AVIF support on paid tiers.
CDN-level conversion. Cloudflare Polish, BunnyCDN Optimizer, Fastly. Converts at the edge based on Accept headers. Zero-configuration once enabled.

For most WordPress sites, Performance Lab + a bulk-convert-once pass with ShortPixel is the right combination. For high-traffic sites, add a CDN layer on top.

Getting AVIF Into WordPress

AVIF is newer, so tooling is thinner.

WordPress core added AVIF upload support in 6.5 (2024).
Performance Lab’s Modern Image Formats module can generate AVIF alongside WebP — it’s off by default, flip the toggle to enable.
Generation is CPU-expensive. On shared hosting, uploading a 12 MP photo that gets converted to all three formats can time out. Either raise PHP max-execution-time or convert asynchronously.

ShortPixel, Imagify, and CDN-level solutions all offer AVIF on paid tiers. Free tiers are WebP-only.

The `<picture>` Element Pattern

For hand-coded theme templates where you control the markup, the modern-image-format pattern is:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

The browser reads top-to-bottom and picks the first format it supports. Chrome and Safari pick AVIF. Older browsers fall through to JPEG. Don’t forget the width/height attributes — they prevent CLS.

The OG Image Exception

Social sharing platforms don’t agree with browsers on image formats. For <meta property="og:image">:

Facebook, Twitter/X, Slack, Discord — handle WebP fine as of 2024.
LinkedIn — mixed; sometimes displays, sometimes falls back to a broken-image icon.
Email clients (Outlook, Apple Mail) — support is spotty.

For OG images specifically, stay on PNG or JPEG. Keep modern formats for on-page <img> elements. The share-preview bandwidth saving isn’t worth the compat risk.

Auditing Your Site’s Image Formats

Open Chrome DevTools → Network tab → filter “Img”.
Reload the page.
Sort by “Type” column. Every image that shows as png or jpeg is a conversion candidate.
Check the “Size” column — anything above 200 KB is a priority target.

For a site-wide pass: PageSpeed Insights flags every non-modern image on every tested page. Or crawl with Screaming Frog’s Images report for a bulk inventory.

The Technical Difference Between WebP, AVIF, and JPEG-XL

All three are modern image formats designed to replace JPEG. They use different compression approaches, with different trade-offs:

WebP (Google, 2010) — based on the VP8 video codec. Lossy + lossless + animated modes. Mature encoding tools, wide support.
AVIF (AOMedia, 2019) — based on the AV1 video codec. Better compression than WebP at equal quality, especially on photos. Newer tooling, heavier encoding CPU.
JPEG-XL (Joint Photographic Experts Group, 2021) — a fresh design, not derived from a video codec. Best compression of the three, plus lossless JPEG recompression. Stalled by Chrome’s 2022 decision to remove support.

Ecosystem momentum matters more than compression. WebP is where the tools, plugins, CDNs, and documentation are. AVIF is closing the gap. JPEG-XL is in Firefox limbo.

Picking Quality Settings That Don’t Show Artifacts

Quality settings aren’t comparable across formats. “Quality 80” in WebP is different from “Quality 80” in AVIF which is different from “Quality 80” in JPEG. Rough equivalence table for photos at web-appropriate resolution:

Format	Web-safe quality	Notes
JPEG	75–85	Below 70, banding on gradients becomes visible
WebP (lossy)	70–80	10–15 points lower than JPEG for equivalent visual quality
AVIF	50–65	Much lower numbers, still visually superior
PNG (lossless)	Compression level 9	Size determined by pixel entropy, not a quality knob

Ship WebP quality 75 as a default. Bump to 80 for hero images. Drop to 70 for below-the-fold photos where sharpness matters less.

Responsive Images: The `srcset` + `picture` Combo

Modern responsive images combine format negotiation (picking WebP vs JPEG) with resolution negotiation (picking 800w vs 1600w). The full pattern:

<picture>
  <source
    type="image/avif"
    srcset="hero-800.avif 800w,
            hero-1200.avif 1200w,
            hero-1600.avif 1600w"
    sizes="(min-width: 1200px) 1200px, 100vw">
  <source
    type="image/webp"
    srcset="hero-800.webp 800w,
            hero-1200.webp 1200w,
            hero-1600.webp 1600w"
    sizes="(min-width: 1200px) 1200px, 100vw">
  <img
    src="hero-1200.jpg"
    srcset="hero-800.jpg 800w,
            hero-1200.jpg 1200w,
            hero-1600.jpg 1600w"
    sizes="(min-width: 1200px) 1200px, 100vw"
    width="1200" height="675"
    alt="Description"
    loading="lazy"
    decoding="async">
</picture>

The browser picks one <source> based on format support, then picks one srcset entry based on viewport + DPR. Three formats × three sizes = 9 files shipped per image, but only one is ever downloaded per page view.

Integrating Modern Images with WordPress

WordPress’s native image handling in 2026 includes:

Automatic srcset generation for responsive images (since 4.4).
Lazy-loading by default via loading="lazy" (since 5.5).
Native WebP and AVIF upload support (since 6.5 for both formats).
Performance Lab plugin adds WebP/AVIF generation for uploads.

What WordPress still doesn’t do natively in 2026:

Bulk-convert existing media library to modern formats. You need a plugin.
Emit the full <picture> pattern. the_post_thumbnail() still renders a single <img> with srcset.
Ship AVIF in srcset alongside WebP. Performance Lab adds it; core doesn’t.

Bulk Converting an Existing Media Library

Running wp media regenerate after installing Performance Lab regenerates thumbnails for every attachment. With Modern Image Formats enabled, regeneration also produces WebP (and optionally AVIF) versions.

Scale considerations:

~2 seconds per image on modern hardware. 1000 images = ~30 minutes. 10,000 images = ~6 hours.
Runs synchronously. Use screen or tmux if you care about disconnecting.
Disk space doubles (roughly) — original + WebP + AVIF side by side. Plan accordingly.
Uploads directory write load spikes during the run. A CDN in front absorbs much of the downstream impact.

For really large libraries (100,000+), use ShortPixel or Imagify’s background processing — they chunk the work into smaller batches and resume gracefully on timeout.

CDN-Level Image Optimization

CDN-level conversion is the lowest-maintenance option. The CDN reads the Accept header from each request, determines what formats the browser supports, and serves the optimal format dynamically without you having to pre-generate anything.

Cloudflare Polish (Pro plan) — converts to WebP on the fly. AVIF in paid tiers.
BunnyCDN Optimizer — cheap, WebP + AVIF, works with any origin.
Fastly Image Optimization — enterprise pricing, most sophisticated.
Cloudinary — full-service image service, includes transformations.

CDN-level conversion is ideal for sites that can’t or won’t run a conversion plugin. The trade-off is that you’re renting the optimization layer, so if you move CDNs you lose it.

Auditing Your Site’s Image Performance

Open Chrome DevTools → Network tab → filter Img.
Reload. Sort by Size descending.
Anything above 200 KB is a candidate for conversion or resizing.
Anything above 500 KB is hurting LCP.
Anything above 1 MB is a bug — usually an un-resized original loaded at thumbnail size in the markup.

For site-wide audits, PageSpeed Insights flags every unoptimized image under the “Serve images in next-gen formats” and “Properly size images” opportunities. Running it on a handful of representative pages surfaces 80% of the issues.

The Hosting and Bandwidth Economics

For a site with 100k monthly visitors, 10 images per page, and a 1.2 MB average PNG vs 180 KB WebP, the math:

PNG: 100k × 10 × 1.2 MB = 1.2 TB/month.
WebP: 100k × 10 × 180 KB = 180 GB/month.

On a managed-WordPress host that charges for egress above 500 GB ($0.10/GB), that’s $700/month saved. On a CDN with free origin fetches, it’s cheaper still. Even for small sites, the bandwidth math becomes meaningful when the site takes off.

The Accessibility Link

Modern image formats have an accessibility angle that rarely gets discussed: smaller images load faster for users on slower connections, older devices, and cellular plans with data caps. A 1.2 MB hero image on a 2G connection takes 24 seconds. The same image as a 200 KB WebP takes 4 seconds. That’s the difference between “your site is usable” and “your site is broken” for a meaningful segment of the global audience.

The AVIF Encoding Cost Problem

AVIF compression is CPU-expensive. Encoding a 12-megapixel photo takes 15-40 seconds depending on settings. This has operational implications:

Uploading 50 photos at once can time out on shared hosting — PHP’s 30-second default max_execution_time is exceeded.
Bulk-regenerating a 5000-image media library in AVIF is an overnight job, not a coffee-break task.
On-the-fly encoding (CDN-level) costs more per request than WebP encoding.

Mitigations:

Encode once, at upload. Never on-the-fly unless the CDN handles it.
Raise max_execution_time to 120+ seconds for the WordPress admin.
Chunk bulk regenerations via WP-CLI, not via admin buttons.
For sites over 10,000 images, pay for ShortPixel or Imagify rather than running CPU on your own server.

The `loading` and `decoding` Attributes

Modern browsers support two attributes that massively affect LCP without changing file sizes:

loading="lazy" — defer loading below-the-fold images until the user scrolls near them. Default for WordPress since 5.5.
loading="eager" — load immediately. Use for the LCP image.
decoding="async" — tells the browser to decode off the main thread.
decoding="sync" — inline decode, used when the image must be ready before first paint. Rare.
fetchpriority="high" — prioritise this resource in the network queue. Use sparingly, only on the LCP image.

The combination for the hero image: loading="eager" decoding="sync" fetchpriority="high" plus a <link rel="preload"> hint in the head.

Image Alt Text: The Accessibility + SEO Double-Win

Modern image formats cut bytes, but bytes don’t describe content. Alt text does both jobs at once — accessible to screen readers, indexable by Google Images.

Practical rules:

Describe the image’s purpose, not its pixels. “Dashboard showing a 40% growth in organic traffic” beats “bar chart”.
Decorative images get alt="", explicitly. Missing alt is different to empty alt.
Length: 100-125 characters is the sweet spot for both screen-reader comprehension and image-search relevance.

Automated Image Optimization Pipelines

For sites that publish heavy image volumes — news, e-commerce, photography — manual upload-and-convert doesn’t scale. A production pipeline:

Editor uploads the original to WordPress Media Library.
Hook on wp_generate_attachment_metadata queues a background job.
Background worker generates WebP + AVIF variants with tuned quality settings.
Worker uploads all variants to the CDN or object store.
WordPress attachment metadata records the variant URLs for template rendering.

This keeps editor experience snappy (synchronous upload completes fast) while ensuring all images reach the front-end optimised.

Image Dimensions and Core Web Vitals

CLS scores crumble when images don’t declare dimensions. WordPress sets width and height attributes on images uploaded through the Media Library, but not always on images hot-linked in HTML blocks or inserted via page builders. Audit:

Open a representative page.
Chrome DevTools → Elements → expand an <img>.
Confirm width and height attributes are present.
If missing, identify the source — page builder, block, or manual HTML — and fix there.

Responsive Image Quality by Device

High-DPI phones demand sharp images. Low-end Android tablets on cellular connections benefit more from smaller files than from pixel-perfect sharpness. srcset can ship both — the browser picks based on DPR and viewport width.

Recommended variants per upload: 640w, 1024w, 1440w, 2048w. Four variants covers 95% of real devices without ballooning storage.

Migration Path: From PNG-Only to Modern-Formats Site

Typical migration steps for an existing site: install Performance Lab, enable Modern Image Formats, run wp media regenerate on the full library. Time: 2-6 hours depending on library size. Result: every uploaded image now has WebP variants automatically served to supporting browsers.

If you want AVIF as well, enable the AVIF toggle in Performance Lab and re-regenerate. Time doubles. Verify with Chrome DevTools Network tab that .avif files are being served.

Progressive Image Enhancement: BlurHash and LQIP

Beyond format choice, there’s a user-experience technique worth knowing: show a tiny, blurry placeholder while the full image loads. Two common implementations:

LQIP (Low-Quality Image Placeholder) — a 20-40px version of the image, base64-encoded, CSS-blurred while loading. Adds ~500 bytes per image; transforms perceived performance.
BlurHash — a 20-30 character encoded hash that generates a smooth gradient placeholder. Smaller than LQIP, faster to decode.

Either technique eliminates the “blank-space-then-image-pop” experience. WordPress doesn’t ship this natively, but plugins like Kadence Blocks and some page builders include it.

Modern Image Formats and Core Web Vitals Alignment

Every modern-image-format decision ultimately serves Core Web Vitals. The specific chain: smaller files download faster, LCP improves, search rankings improve, click-through rate improves, bounce rate improves. Investments here compound in ways that more visible SEO work often doesn’t.

Track the metric chain end-to-end: CDN bytes saved per month, LCP delta, CrUX pass rate, Search Console impressions. When all four move together, the format migration is working.

Frequently Asked Questions

Does converting to WebP hurt SEO?

No. Google explicitly prefers modern formats — PageSpeed Insights flags non-WebP images as a performance issue, which indirectly helps ranking via Core Web Vitals. The URLs of your images change, but search equity moves with the redirect (or automatically, if WordPress serves the same URL and just changes the returned format).

Should I delete the original PNG/JPEG after converting?

No. Performance Lab and friends keep the original and serve the modern format only to browsers that support it. Deleting the originals breaks the fallback.

Is AVIF worth the complexity over WebP?

For photo-heavy sites with high traffic, yes — the 25% size savings vs WebP compounds across millions of requests. For blog sites with a dozen images per page, WebP alone is usually enough.

What about SVG?

SVG is the right choice for logos, icons, and infographics — anything that’s vector by nature. It’s not a raster replacement. WebP + SVG is the modern combination.