WordPress WebP Conversion: Plugins, CLI & CDN Options

WebP delivers 25–34% smaller file sizes than JPEG at equivalent visual quality, and 26% smaller than PNG — making image format conversion one of the highest-ROI performance tasks on any WordPress site. The decision isn't whether to serve WebP; it's which conversion layer fits your stack.

Why WebP Conversion Is More Complex Than It Looks

Converting images is the easy part. The hard part is ensuring WordPress actually serves the converted files to every request path: standard <img> tags, srcset attributes, Gutenberg block references, ACF image fields, CSS background images, lazy-loaded gallery scripts, and OG meta tags. Miss one and you're partially converted — still failing that Lighthouse audit.

The architecture of your solution determines which paths get covered. Let's work through each layer.

Plugin-Based Conversion: Easiest Entry Point

Plugin conversion handles the full WordPress lifecycle — upload, serve, and (usually) rewrite — in a single install. These tools hook into wp_handle_upload to convert on ingest, generate WebP sidecar files alongside originals, and use .htaccess or NGINX rewrite rules to serve the correct format based on Accept headers.

Converter for Media (formerly WebP Converter for Media)

Free tier covers unlimited conversions but serves via a PHP redirect script, which adds latency. The paid version (~$29/year) serves via server rewrites. Configuration options include:

• Lossy vs. lossless per mime type
• Separate quality settings for JPEG-to-WebP and PNG-to-WebP
• Exclusion rules by path or size

Caveat: The PHP redirect path on shared hosts can become a bottleneck under load. On managed environments running NGINX, you'll need to add the rewrite rules manually or the plugin falls back to the slow redirect.

Imagify

Imagify uses Imagify's cloud API, meaning conversions happen off-server. Free tier: 20MB/month (roughly 200–400 images depending on size). Paid plans start at $4.99/month for 500MB. The plugin rewrites <img> tags in rendered HTML via an output buffer, which catches most but not all image references.

Key settings worth changing from defaults:

Optimization level: Aggressive (not Ultra — Ultra is lossy enough to introduce visible artifacts on product photography)
Convert to WebP: Enabled
Resize large images: Set a sane max-width (2400px for most sites)
Backup original: Always enabled until you've verified output quality

ShortPixel

ShortPixel's approach is similar to Imagify but supports AVIF as a secondary fallback format. API credits are per image (not per month), which works well for sites with infrequent uploads. At $9.99 for 10,000 credits, it's cost-effective for smaller libraries but can get expensive for large WooCommerce catalogs with multiple generated thumbnail sizes.

ShortPixel also offers a CLI-adjacent tool — shortpixel-php — for batch processing outside WordPress, covered in the next section.

CLI Batch Conversion: The Right Tool for Large Libraries

For libraries over a few thousand images, CLI conversion is faster, cheaper, and leaves no runtime dependency. You convert once, verify quality, then configure the server to serve the results — no plugin running on every request.

cwebp Direct Conversion

Install cwebp on your server (part of the webp package on most Linux distros):

sudo apt install webp

Batch convert an entire uploads directory:

find /var/www/html/wp-content/uploads -type f \( -name "*.jpg" -o -name "*.jpeg" -o -name "*.png" \) | while read img; do
  cwebp -q 82 "$img" -o "${img%.*}.webp"
done

Quality setting notes:

• -q 82 is a reasonable lossy default for photography. Run a visual diff against originals before committing.
• Use -lossless flag for PNG files containing text, icons, or UI elements where pixel-perfect accuracy matters.
• -q 85 -m 6 increases compression effort (slower) — useful for batch overnight jobs.

NGINX Rewrite Rules for Sidecar WebP Files

Once .webp sidecar files exist alongside originals, configure NGINX to serve them when the browser sends Accept: image/webp:

map $http_accept $webp_suffix {
    default "";
    "~*webp" ".webp";
}

server {
    location ~* \.(jpg|jpeg|png)$ {
        add_header Vary Accept;
        try_files $uri$webp_suffix $uri =404;
    }
}

This is zero-PHP-overhead WebP delivery. The browser gets the right format; WordPress doesn't know or care. For Apache hosts, the equivalent .htaccess block uses RewriteCond %{HTTP_ACCEPT} image/webp.

WP-CLI + Imagick for WordPress-Aware Conversion

If you need WordPress to regenerate all registered thumbnail sizes in WebP, use WP-CLI with a custom script or the wp media regenerate command after enabling WebP output in your theme or plugin:

wp media regenerate --yes

This is slower than direct cwebp but ensures all sizes registered by add_image_size() get converted, not just the originals. Requires PHP Imagick with WebP support compiled in — verify with:

php -r "phpinfo();" | grep -i webp

According to W3Techs, PHP 8.1+ with Imagick is now available on the majority of managed WordPress hosts (2024), but Imagick's WebP support still depends on the ImageMagick version compiled against libwebp. Always verify before assuming it works.

CDN-Level Transformation: Convert Without Touching Origin

CDN-level transformation is the cleanest architectural option when you control the CDN but not the origin server. Images are converted and cached at the edge; your origin stores only originals.

Cloudflare Polish

Available on Cloudflare Pro ($20/month and above). Polish automatically serves WebP to supporting browsers with no configuration beyond enabling it in the Speed → Optimization panel. Lossy and lossless modes are available. Cloudflare caches the converted variant, so the first request triggers conversion; subsequent requests serve from cache.

Limitation: Polish doesn't convert images served from external origins or object storage unless those are proxied through Cloudflare.

Cloudinary

Cloudinary's WordPress plugin (cloudinary-image-management-and-manipulation-in-the-cloud-cdn) offloads your entire media library to Cloudinary's CDN and applies f_auto,q_auto transformations that automatically select WebP or AVIF based on browser support. This is the most powerful option for sites with complex image transformation needs (crop, resize, overlay, face detection) but introduces a hard vendor dependency on your media URLs.

Free tier includes 25GB storage and 25GB bandwidth/month — adequate for small sites.

BunnyCDN Bunny Optimizer

For sites on managed WordPress hosting that already runs LiteSpeed, BunnyCDN's Bunny Optimizer ($9.50/month base) adds on-the-fly WebP conversion and Smart Resizing at the edge. This pairs well with object storage offloading — a pattern covered in the WordPress media offloading guide.

Handling Legacy Image References

Converting files without updating references means browsers still request the original URLs. This is the most commonly skipped step and the reason "I installed a WebP plugin" doesn't always move Lighthouse scores.

Where Legacy References Live

1. Post content (wp_posts.post_content): Classic editor embeds absolute URLs. Gutenberg stores relative paths that resolve through WordPress's media query — plugin-based rewriting usually catches these.
2. ACF image fields: Stored as attachment IDs (safe) or serialized URLs (dangerous to search-replace). Always use the ID-based ACF return format.
3. Theme templates: Hardcoded get_template_directory_uri() paths, CSS background-image in <style> blocks, inline styles in page builders.
4. OG/Twitter meta tags: Yoast and RankMath generate these from attachment metadata — if you've converted and the plugin knows about the WebP version, these update automatically.
5. Sitemaps: Google's image sitemap extensions. If your sitemap lists JPEG URLs, Googlebot fetches JPEGs. Ensure your sitemap plugin pulls from the same source as your delivery layer.

Database URL Rewriting (Use With Caution)

If you've used CLI conversion and your plugin doesn't rewrite URLs, you can update post_content references with WP-CLI:

wp search-replace 'uploads/2024/01/hero.jpg' 'uploads/2024/01/hero.webp' --all-tables

Always run with --dry-run first. And take a full database backup before any search-replace operation — the WordPress backup strategy guide covers snapshot workflows that make this reversible.

For serialized data (ACF, page builder meta), use WP-CLI's built-in serialization-aware replacement rather than raw SQL:

wp search-replace 'old-string' 'new-string' --all-tables --precise

Lossy vs. Lossless: Choosing the Right Compression Mode

The default answer: lossy for photographs, lossless for graphics with text or flat color.

At quality 80–85 lossy, WebP is visually indistinguishable from JPEG for photographic content in most browser contexts. Going below 75 introduces visible artifacts on skin tones and gradients. Going lossless on photographs produces files larger than the original JPEG, defeating the purpose.

For PNG source files:

• UI screenshots, icons, logos with transparency: Lossless WebP. Lossy introduces halos around hard edges.
• Photographic PNGs (someone saved a photo as PNG): Lossy WebP at 82–85. Still smaller than lossless.

According to Google's own WebP study (2023), lossy WebP at quality 75 is perceptually equivalent to JPEG at quality 90 by SSIM metrics. That's your benchmark for calibrating quality settings against your own content.

What Your Hosting Environment Determines

Not every conversion approach works on every host. The matrix matters:

• Shared hosting (cPanel): PHP redirect delivery only. No NGINX rule access. Plugin-based with output buffer rewriting is your only realistic option.
• VPS/unmanaged: Full control. CLI conversion + NGINX rewrite rules is the optimal path. See cPanel alternatives for WordPress hosting if you're managing your own control panel.
• Managed WordPress hosting: Depends on the provider. Some restrict SSH access or cwebp installation. Others — including TopSyde's managed plans starting at $89/mo — run LiteSpeed with WebP output enabled at the server level, meaning plugin rewriting works immediately without .htaccess gymnastics.
• CDN-first architectures: CDN transformation is your cleanest option, since you're already routing all traffic through the edge.

For WooCommerce stores specifically, the volume of product image variants (WooCommerce registers 4+ thumbnail sizes by default) makes CLI batch conversion significantly cheaper than API-based plugins at scale. A 5,000-product catalog with 6 sizes each means 30,000 API credits before you've processed a single new upload.

Frequently Asked Questions

Does converting to WebP break existing image URLs?

Not if you use the sidecar file approach — original files stay in place, and the server (or plugin) serves the .webp version based on browser Accept headers. The original URL remains valid; browsers that don't support WebP still get the JPEG or PNG. Only if you physically replace files or rewrite database URLs do existing references break.

Should I convert PNG files to WebP if they have transparency?

Yes — WebP supports alpha transparency, so transparent PNGs can be converted to lossless WebP with full transparency preserved and a size reduction of 20–40%. Use lossless mode (-lossless flag in cwebp) to avoid artifacts around transparent edges. Lossy WebP handles transparency poorly at lower quality settings.

Will WebP images affect my SEO?

WebP is fully indexed by Google. Googlebot supports WebP and will crawl and index WebP image URLs in sitemaps and structured data. The SEO benefit comes indirectly: smaller images improve LCP and overall page speed, which are confirmed ranking signals. Ensure your image sitemap reflects the URLs actually being served to Googlebot — if your CDN serves WebP but your sitemap lists JPEG, there's a minor crawl inefficiency but no penalty.

How do I verify WebP is actually being served?

Open Chrome DevTools → Network tab → filter by "Img" → click any image request → check the Response Headers for Content-Type: image/webp. You can also use the free WordPress malware scanners blind spots methodology as a mental model: just as you'd verify security tool coverage, verify your WebP delivery by checking actual HTTP responses rather than assuming plugin settings are working.

Is AVIF worth using instead of or alongside WebP?

AVIF offers 20–50% better compression than WebP at equivalent quality (Cloudinary, 2023) but has higher encoding CPU cost and less universal browser support (currently ~90% vs WebP's ~97%). The practical approach: use AVIF as a <picture> source with WebP fallback if you control your markup, or use a CDN like Cloudinary that handles format negotiation automatically via f_auto. For most WordPress sites in 2026, WebP alone is sufficient.

Marcus Webb

DevOps & Security Lead

12+ years DevOps, Linux & cloud infrastructure certified

Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.

XLinkedIn