Image formats are one of the most consistently underoptimized levers in technical SEO. Most sites are still serving JPEG files that were uploaded five years ago, or they switched to WebP and called it done. In 2026, three next-generation formats — AVIF, WebP2, and JPEG XL — offer meaningfully different performance profiles, and the choice between them has real implications for Core Web Vitals, LCP scores, and page speed rankings.
This guide is for technical SEOs and developers who need to make concrete format decisions, not read another article that concludes “it depends.” It does depend — but on specific, measurable factors that we’ll walk through. By the end, you’ll know which format to use for which image type, which browser support gaps still matter in 2026, and how to implement a format delivery strategy that maximizes performance across your entire user base.
The State of Next-Gen Image Formats in 2026
The format landscape has clarified significantly since 2023. Here’s where things stand:
AVIF (AV1 Image File Format)
AVIF is derived from the AV1 video codec and produces the smallest file sizes of any broadly supported format for most image types. At equivalent visual quality, AVIF typically beats WebP by 20-35% in file size and beats JPEG by 40-60%. Browser support in 2026 is strong: Chrome (85+), Firefox (93+), Safari (16+), and Edge (121+) all support AVIF. Global coverage is approximately 94% of browser traffic.
AVIF’s weakness is encoding speed. A high-quality AVIF encode at full quality can take 3-10x longer than an equivalent WebP encode on the same hardware. For sites with large image libraries or user-generated content that needs real-time encoding, this matters. For pre-encoded static assets, it doesn’t.
AVIF also handles high-resolution, high-dynamic-range content particularly well — it supports 10-bit and 12-bit color depth natively, making it the right choice for photography-heavy sites where color accuracy matters.
WebP2
WebP2 is Google’s successor to WebP, under development since 2020. As of 2026, WebP2 has not achieved stable status or broad browser adoption. It remains an experimental format with no production browser support outside of development builds. Chrome does not yet ship WebP2 support in stable releases.
The honest answer for 2026: WebP2 is not a production format. Don’t use it in production. Watch it — it shows promising compression characteristics in testing, roughly 20-30% better than AVIF in some scenarios — but it’s not ready. Anyone telling you to deploy WebP2 on a production site today is wrong.
JPEG XL
JPEG XL (JXL) had a troubled 2023 when Chrome removed its experimental support, citing the format’s development maturity. That decision reversed: Chrome restored JPEG XL support in version 118 (late 2023) behind a flag, and stable support shipped in Chrome 122 (early 2024). Safari added JPEG XL support in iOS 17.0 and macOS Sonoma. Firefox added support in version 128 (2024).
In 2026, JPEG XL has approximately 88-90% global browser coverage — meaningful but still below AVIF’s ~94%. The gap is primarily older Chrome Android versions and some Samsung Internet versions.
JPEG XL has a unique capability that AVIF lacks: lossless recompression of existing JPEG files. A JPEG can be transcoded to JXL with zero quality loss at 20-25% smaller file size, and the original JPEG can be perfectly reconstructed from the JXL file. This makes JXL attractive for archival workflows and sites that need to preserve original quality for legal or professional reasons.
For typical web images, JPEG XL and AVIF produce similar compression at similar visual quality levels. JPEG XL tends to perform better on photographs with fine detail (hair, fabric textures, foliage). AVIF tends to perform better on images with large flat color areas and gradients.
Side-by-Side Compression Benchmarks
Real-world compression ratios vary by image content, encoder settings, and target quality level. These benchmarks use a representative sample of web-typical images (photography, product shots, illustrations) at equivalent visual quality (SSIM 0.95):
- JPEG (baseline): 100% file size
- WebP: 58-65% of JPEG (35-42% reduction)
- AVIF: 40-55% of JPEG (45-60% reduction)
- JPEG XL: 42-58% of JPEG (42-58% reduction)
- WebP2 (lab, not production): 30-40% of JPEG (60-70% reduction)
For LCP images — the single most important image for Core Web Vitals — switching from JPEG to AVIF typically reduces payload by 45-60%, which directly translates to LCP improvement on bandwidth-constrained connections. A 300KB JPEG hero image becomes 120-165KB in AVIF. On a 3G connection, that’s 2+ seconds of load time saved.
Core Web Vitals Impact
LCP (Largest Contentful Paint)
LCP is where image format choice has the most direct SEO impact. The LCP element is typically the hero image, featured image, or first above-the-fold product photo. Reducing its file size reduces time-to-LCP, which reduces your LCP score.
The calculation is straightforward: LCP time ≈ (Time to First Byte) + (Image transfer time) + (Image decode time). Format choice affects the last two terms.
AVIF and JPEG XL both have decode overhead that JPEG doesn’t — the more sophisticated compression algorithms require more CPU to decompress. On high-end desktop CPUs, this difference is negligible (5-15ms). On low-end Android devices, AVIF decode can add 50-100ms. Run device-representative tests, not just desktop tests, when evaluating LCP impact.
CLS (Cumulative Layout Shift)
Format choice doesn’t directly affect CLS, but it’s worth noting: always specify explicit width and height attributes on images regardless of format. Layout shift caused by images without dimensions is a format-agnostic problem that’s easy to fix and has meaningful CLS impact.
INP (Interaction to Next Paint)
AVIF’s heavier decode can affect INP on pages where many images are decoded simultaneously (image galleries, product grids). If you’re implementing AVIF on a gallery-heavy page, test INP specifically on mid-range Android devices. JPEG XL has slightly lighter decode overhead than AVIF in most browser implementations, making it preferable for these scenarios.
Implementation Strategy: Format Delivery in 2026
The right implementation serves the best-supported format each browser can handle, with a guaranteed fallback.
The <picture> Element Approach
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.jxl" type="image/jxl">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description" width="1200" height="630">
</picture>
Browser selects the first format it supports. Given current support levels, this serves AVIF to ~94% of users, JPEG XL to most of the remainder, WebP as a further fallback, and JPEG only to legacy browsers.
The tradeoff: this requires storing 3-4 versions of every image, which increases storage costs (typically 30-50% more storage than JPEG-only, offset by CDN bandwidth savings) and complicates your image pipeline.
CDN-Level Format Negotiation
A simpler approach for large sites: use a CDN or image transformation service that handles format negotiation automatically based on the Accept header. Major options in 2026:
- Cloudflare Images: Automatic AVIF/WebP delivery based on browser support, Polish optimization, built into most Cloudflare plans
- Cloudinary: f_auto parameter serves the optimal format per request, supports AVIF, JPEG XL, and WebP with full control
- imgix: auto=format parameter with AVIF and WebP support; JPEG XL support added in 2024
- Fastly Image Optimizer: Server-side format negotiation with AVIF support
CDN-level format negotiation reduces engineering complexity dramatically. You upload JPEG or PNG originals; the CDN handles format conversion and serves the optimal output. For most sites above 10,000 images, this is the right approach.
Build-Time Conversion Pipeline
For static sites or sites where CDN costs are a concern, build format conversion into your deployment pipeline:
- Sharp (Node.js): Fast, high-quality AVIF and WebP encoding; JPEG XL support via libvips 8.14+
- libvips: The underlying library powering most image processing tools; supports all three formats natively
- Squoosh CLI: Google’s command-line tool for batch encoding; supports AVIF, WebP, and JPEG XL
- cavif-rs / cavif: AVIF-specific encoders with more control over encoding parameters than general-purpose tools
Format Selection Decision Framework
Use this decision tree for choosing formats by use case:
- LCP hero images, product photography: AVIF primary, JPEG XL fallback, WebP further fallback. Prioritize file size reduction for bandwidth impact.
- Photography with fine detail (hair, fabric, nature): JPEG XL primary, AVIF secondary. JXL preserves high-frequency detail better at equivalent file sizes.
- UI elements, screenshots, images with text: WebP (lossless) or PNG. Lossy AVIF/JXL at low quality settings introduces visible artifacts on hard edges.
- Image galleries, grids (decode performance matters): JPEG XL primary (lighter decode), AVIF secondary.
- User-generated content (real-time encoding needed): WebP (fast encoding). AVIF/JXL for async re-encoding after upload if quality/size matters.
- Archival and lossless JPEG replacement: JPEG XL lossless. Unique capability to perfectly reconstruct original JPEG.
Measuring the SEO Impact
After implementing next-gen formats, measure impact through:
- PageSpeed Insights API: Compare LCP, TBT, and Speed Index before/after. Run on mobile at simulated 4G to get a realistic picture.
- CrUX data: Check your origin’s LCP distribution in the Chrome UX Report 4-6 weeks after deployment. Field data lags lab data by weeks.
- Google Search Console Core Web Vitals report: Monitor URL-level CWV status changes. Expect 4-8 weeks for GSC to reflect improvements.
- CDN bandwidth reports: Verify actual bandwidth reduction — this validates that format conversion is working correctly across your user base.
Realistic expectations: a well-executed AVIF migration on a photography-heavy site should produce 20-40% reduction in image payload, 15-30% LCP improvement on mobile (4G) simulation, and measurable CrUX improvement over 6-8 weeks.
Frequently Asked Questions
Should I drop WebP support now that AVIF has better browser coverage?
Not yet. AVIF has ~94% coverage, meaning ~6% of your traffic (typically older devices and some Samsung Internet users) doesn’t support it. WebP at ~97% coverage still serves as a valuable fallback layer between AVIF and JPEG. Keep the format stack: AVIF → WebP → JPEG. The storage cost of maintaining both is minimal compared to the bandwidth savings on AVIF-supported browsers and the quality improvement over JPEG for the WebP fallback group.
How does AVIF affect server-side rendering and Time to First Byte?
AVIF doesn’t affect TTFB at all — it’s a client-side delivered format. TTFB is determined by your server response time, not image format. The image format only matters after the page HTML is delivered and the browser begins fetching resources. Focus on TTFB separately through server optimization, caching, and CDN edge delivery.
Is JPEG XL worth implementing given Chrome’s history of removing support?
Chrome’s removal of JPEG XL in 2022 was during an experimental flag phase, not a stable feature removal. The current support in Chrome 122+ is stable and not behind a flag. The format is now part of Chrome’s standard image support. Implement JPEG XL as a fallback between AVIF and WebP — it costs you one additional image variant in storage but provides better quality than WebP for the ~6% of users who don’t get AVIF.
How do I handle animated images in next-gen formats?
AVIF supports animation and can replace animated GIFs and WebP animations. Animated AVIF typically achieves 30-50% smaller files than animated WebP at equivalent visual quality. The encoding pipeline is more complex — you need tools like ffmpeg with AVIF support for video-to-AVIF conversion. For purely decorative animations, consider whether a CSS animation or lightweight video (MP4/WebM) serves the use case better than animated images — they often deliver better performance.
What compression quality setting should I use for AVIF and JPEG XL?
There’s no universal answer — quality is content-dependent. A practical starting point: AVIF quality 60-75 (on a 0-100 scale) and JPEG XL quality 75-85 produces results visually comparable to JPEG quality 80-85 for most photographic content. Always validate with perceptual quality metrics (SSIM, DSSIM, or BUTTERAUGLI) rather than just file size comparisons, and do visual spot checks on your specific content types. Product images with text overlays need higher quality settings than nature photography.
