WebP in 2026: Browser Support, WordPress Setup, and Conversion Tips

For more than a decade, JPG and PNG quietly ruled the web. Every product photo, hero banner, and blog thumbnail leaned on formats designed in the 1990s, long before Retina displays, mobile networks, and Core Web Vitals made page weight a ranking factor. WebP changed that math. In 2026, it is no longer an experimental format or a "progressive enhancement" you bolt on with a polyfill. It is the default image format of the modern web, shipped by every major browser, supported by every major CMS, and preferred by every serious performance engineer.

This guide explains where WebP stands in 2026, how to deploy it on WordPress and static sites, how it compares to JPG, PNG, and AVIF, and the practical conversion workflows that turn theory into shipped pixels.

What is WebP and Why Google Created It

WebP is an open, royalty-free raster image format developed by Google and first released in 2010. It was derived from the VP8 video codec (the same codec behind WebM video) and later extended with a separate lossless mode based on research from the Skia and Chrome teams. Google's goal was straightforward: reduce the bandwidth cost of serving images on the web without degrading visible quality.

Unlike JPG, which supports only lossy 8-bit color and has no alpha channel, WebP supports:

• Lossy compression with better quality-per-byte than JPG
• Lossless compression that typically beats PNG by 20-30%
• Full 8-bit alpha transparency in both lossy and lossless modes
• Animation, making it a direct replacement for animated GIF
• ICC profiles, EXIF metadata, and XMP metadata
• Color depth up to 8 bits per channel (10-bit is handled by AVIF)

In practical terms, WebP is a single format that replaces three legacy ones. You no longer need JPG for photos, PNG for UI assets with transparency, and GIF for short animations. One encoder, one decoder, one image tag.

WebP in 2026: Adoption and Browser Support

WebP adoption has reached what the industry calls "baseline" status. According to public Can I Use data and HTTP Archive crawls in 2026, WebP sits at roughly 97% global browser support. The remaining 3% is made up almost entirely of legacy Internet Explorer installations in regulated enterprise environments and a handful of older Android WebView builds on devices that are no longer receiving updates.

Browser Support Table

The pivotal moment for WebP was Apple adding support in Safari 14 on iOS 14 and macOS Big Sur in September 2020. Before that date, developers had to ship a JPG or PNG fallback using the picture element. Six years later, those fallbacks are no longer strictly necessary for the vast majority of audiences, though many teams still keep them for defense in depth.

HTTP Archive's State of the Web reports in 2026 show that WebP now accounts for roughly 35-40% of all image bytes served on the web, with AVIF taking another 8-10% and JPG slowly shrinking to around 40%. PNG usage has collapsed to around 12%, mostly concentrated in logos, icons, and UI assets where designers have not yet migrated pipelines.

File Size Savings vs JPG and PNG

The performance case for WebP is straightforward. Google's original research claimed 25-34% smaller files than JPG at equivalent quality, and independent tests in 2026 continue to validate that range. Real-world savings depend heavily on the source image, encoder settings, and target quality, but typical numbers look like this:

• Photographic content (JPG source at quality 85): WebP is typically 25-35% smaller at visually matched quality
• UI assets and screenshots (PNG source): WebP lossless is typically 20-30% smaller than PNG
• Images with transparency (PNG-24 source): WebP lossy with alpha is often 60-80% smaller than PNG-24
• Short animations (GIF source): Animated WebP is typically 60-90% smaller than GIF at equivalent frame count

For a concrete example, a 1920x1080 hero image exported from a camera might be 480 KB as JPG at quality 85, 320 KB as WebP at equivalent perceived quality, and 210 KB as AVIF. On a page with ten such images, moving from JPG to WebP saves roughly 1.6 MB of transfer per pageview. Multiply that across a site with millions of pageviews and the CDN and Largest Contentful Paint improvements are substantial.

If you want to see the difference on your own files, you can try JPG to WebP and PNG to WebP directly in the browser before committing to a pipeline change.

WebP Lossy vs WebP Lossless: When to Use Each

WebP has two distinct compression modes, and choosing correctly matters more than most developers realize.

WebP lossy uses block-based prediction and transform coding derived from VP8. It is the right choice for photographs, screenshots of photographs, marketing imagery, product shots, and any content where the source was already lossy (such as a JPG you are re-encoding). Quality settings run from 0 to 100, with 75-85 being the sweet spot for web delivery.

WebP lossless uses a completely different algorithm based on LZ77-style dictionary compression, color transforms, and entropy coding. It is the right choice for UI screenshots, logos, diagrams, charts, line art, and any image where pixel-perfect reproduction matters. Lossless WebP almost always beats PNG on file size while preserving every pixel.

A practical rule: if your source is PNG and contains flat colors, text, or sharp edges, use lossless. If your source is JPG, or the image is a photograph, use lossy. Mixing this up produces either bloated files or visible compression artifacts. For a deeper treatment of the underlying tradeoffs, see our guide on lossy vs lossless compression.

Comparison: WebP vs JPG vs PNG vs AVIF

Setting Up WebP on WordPress

WordPress has supported WebP uploads natively since version 5.8 (July 2021), and WebP thumbnail generation since version 6.1 (November 2022). In 2026, you do not need a plugin to simply upload and display WebP files. You do still want a plugin if you need to automatically convert existing JPG and PNG libraries, serve WebP conditionally based on browser support, or regenerate thumbnails.

Recommended WordPress Plugins

ShortPixel Image Optimizer remains the most complete option. It converts existing media libraries to WebP (and AVIF), stores the originals, serves WebP via picture tags or rewrite rules, and handles CDN integration. Its credit-based pricing scales well for small sites and has an unlimited tier for agencies.

Imagify (by WP Rocket) offers similar functionality with a cleaner UI and tight integration with the rest of the WP Rocket ecosystem. It is a strong choice if you already run WP Rocket for caching.

EWWW Image Optimizer is the most flexible option for self-hosted pipelines. It can optimize locally (no API credits) using bundled binaries, and its Easy IO CDN converts and serves WebP or AVIF on the fly.

Smush (by WPMU DEV) handles bulk conversion and lazy loading and integrates WebP serving through its CDN. It is the most beginner-friendly of the four.

All four plugins do essentially the same job. Pick based on pricing model, UI preference, and whether you need local-only processing.

Serving WebP via .htaccess with Fallback

If you want server-level WebP delivery without a plugin, the classic Apache rewrite rule still works:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} (.*)\.(jpe?g|png)$
  RewriteCond %1.webp -f
  RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
</IfModule>

<IfModule mod_headers.c>
  Header append Vary Accept env=REDIRECT_accept
</IfModule>

AddType image/webp .webp

This checks whether the browser sent an Accept header containing image/webp, verifies that a matching .webp file exists next to the original, and transparently rewrites the URL. The Vary: Accept header ensures CDNs and proxies cache the two variants separately. You must still generate the .webp files through a plugin, CLI tool, or build step.

Using the picture Element Directly

For full control, especially on hand-coded themes, the picture element gives you an explicit fallback chain:

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

Browsers pick the first source they support. If you only serve WebP and JPG, you can drop the AVIF line. Always specify width and height to prevent layout shift, and use loading="lazy" on images below the fold.

WebP on Static Sites, Next.js, and CDNs

For static sites and modern frameworks, image handling has moved up the stack. You rarely write picture tags by hand anymore.

Next.js Image component (in both the Pages Router and App Router) automatically serves WebP and AVIF to capable browsers when you use next/image. The built-in image optimizer generates multiple sizes, picks the optimal format from the Accept header, and caches results at the edge. You import your images normally and Next.js handles the rest.

Cloudflare offers Polish and Image Resizing, which transparently convert origin JPG and PNG files to WebP or AVIF at the edge. Polish is enabled with a single toggle in the dashboard. Image Resizing adds on-the-fly transformations via URL parameters.

Cloudinary, imgix, and Bunny Optimizer are dedicated image CDNs that handle format negotiation, resizing, and optimization as a service. They are the right choice when image handling is a core part of your product rather than a deployment concern.

Fastly Image Optimizer and AWS CloudFront with Lambda@Edge offer similar capabilities for teams already invested in those stacks.

On a modern Jamstack setup, the typical pipeline is: author images as high-quality JPG or PNG, commit them to the repo, let the framework or CDN generate optimized WebP and AVIF variants at build time or request time, and serve them with automatic picture markup.

Creating WebP Files

When you need to convert images manually, several tools cover the workflow.

Google Squoosh (squoosh.app) is a free browser-based encoder by the Chrome team. It runs entirely client-side, shows side-by-side quality comparisons, and exposes every encoder setting. It is the best tool for learning how WebP parameters affect output.

Adobe Photoshop has shipped native WebP export since version 23.2 (February 2022). Use File, Save a Copy and pick WebP from the format list. Photoshop exposes quality, lossless mode, and metadata options.

cwebp command-line tool is the reference encoder, shipped by Google as part of libwebp. It is the right choice for batch processing and build pipelines:

cwebp -q 80 input.jpg -o output.webp
cwebp -lossless input.png -o output.webp
cwebp -q 75 -m 6 -af input.jpg -o output.webp

The -m 6 flag uses the slowest, highest-quality compression method. The -af flag enables auto-filter for better quality on complex images.

Online converters like our own JPG to WebP, PNG to WebP, and GIF to WebP tools handle one-off conversions without installing anything. Going the other direction, WebP to JPG and WebP to PNG are useful when a client or platform does not accept WebP uploads.

If you are working with iPhone photos, you will often go through HEIC to JPG first, then JPG to WebP for web delivery.

WebP vs AVIF in 2026

AVIF (AV1 Image File Format) is the newer challenger. Derived from the AV1 video codec, it offers roughly 30-50% smaller files than WebP at equivalent quality, along with 10-bit and 12-bit color depth and better HDR support. In 2026, AVIF browser support sits at around 94% globally, trailing WebP by only a few percentage points after Safari added full AVIF support in version 16.4 in 2023.

So should you skip WebP and go straight to AVIF? Not quite. The practical tradeoffs in 2026 look like this:

Use AVIF when you need the absolute smallest files, you are comfortable with slower encode times (AVIF encoding is 5-10x slower than WebP on CPU), you serve a large volume of images through a CDN or build pipeline that handles format negotiation, or you are delivering HDR or wide-gamut content.

Use WebP when you need fast encoding for user-uploaded content, you are on infrastructure without AVIF encoding support, you need animation (AVIF animation support is still inconsistent), or you need maximum compatibility with slightly older devices and browsers.

The most common production setup in 2026 serves AVIF first, WebP second, and JPG as the final fallback, all via picture or an image CDN. This gives you maximum savings for modern browsers and guaranteed delivery for everything else. For a side-by-side look at the tradeoffs including PNG, see WebP vs PNG vs JPEG comparison.

SEO and Core Web Vitals Implications

Google has confirmed that image format does not directly affect rankings, but it indirectly influences several ranking factors that do matter.

Largest Contentful Paint (LCP) is the Core Web Vitals metric most affected by image format. LCP measures the render time of the largest visible element, which on most pages is a hero image. Shrinking that image by 30% through WebP typically moves LCP by 200-400 ms on 4G mobile connections. Sites that sit near the "good" LCP threshold (2.5 seconds) often cross into green territory purely by migrating hero images to WebP.

Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) are not directly affected by format choice, but smaller images mean less main-thread decode work, which indirectly helps INP on image-heavy pages.

Mobile data costs matter for international audiences. Users on metered connections in emerging markets benefit disproportionately from WebP. Google's own data shows that sites with optimized image formats retain more traffic in regions where mobile data is expensive.

For a broader discussion of how image formats fit into web performance strategy, our guides on PNG vs JPG when to use each and SVG vs PNG comparison cover adjacent tradeoffs.