Back to Community

Why Are My WebP Images Not Loading? A Troubleshooting Guide for Converter for Media

Content

You've installed the 'Converter for Media – Optimize images | Convert WebP & AVIF' plugin, successfully converted your images, and can see the WebP files in the uploads-webpc directory. Yet, when you visit your site, the browser is still loading the original JPEG or PNG files. This is one of the most frequently reported issues with the plugin, and it's almost always related to server configuration, not a problem with the conversion process itself.

Based on an analysis of numerous community support threads, here are the most common reasons and their solutions.

Why This Happens: The Root Cause

The plugin works by using server-level rewrite rules. When a browser requests an image, these rules check two things: 1) if the browser accepts WebP images (Accept: image/webp header), and 2) if a WebP version of that image exists in the uploads-webpc directory. If both conditions are met, the server silently serves the WebP file instead of the original. If this isn't happening, the rewrite rules are not being executed properly on your server.

Common Solutions and How to Test Them

1. .htaccess Configuration (Apache Servers)

This is the most common culprit. The plugin automatically adds rules to your .htaccess file, but other factors can prevent them from working.

  • Conflicting Rules: The WordPress section of your .htaccess file must come after the WebP Converter section. If it comes before, the WordPress rules may override the image redirects.
  • Incorrect Paths: Compare the rewrite rules in your uploads directory .htaccess with those in your root .htaccess. For most standard WordPress installations, the rules should reference paths like /wp-content/uploads-webpc/$1.jpg.webp. If your WordPress is in a subdirectory, the paths generated might be incorrect.
  • mod_rewrite Not Enabled: Confirm with your host that the Apache mod_rewrite module is active.

2. Nginx Server Configuration

The plugin cannot automatically modify Nginx configuration files. You must manually add the rewrite rules provided in the plugin's FAQ to your server's Nginx config block. Simply adding them to an .htaccess file will have no effect, as Nginx ignores these files. This is a common issue for users on Laravel Valet, local development environments, and managed hosting where Nginx is used.

3. IIS Server Configuration

Similarly, IIS on Windows servers does not use .htaccess. The rewrite rules need to be converted into IIS's web.config format. The 'Converter for Media' plugin does not provide an automatic conversion for this, and manual translation is required, which can be complex due to unsupported flags.

4. CDN and Offload Media Plugins

If you use a service like AWS CloudFront or a plugin like Offload Media for S3, the image URLs on your site point to the CDN, not your server. The plugin's rewrite rules on your server never get a chance to run. The converted WebP files also typically remain on your local server and are not pushed to the CDN bucket. Solving this requires advanced CDN configuration to respect the Accept header and serve different image formats, which is often beyond the scope of the plugin's core functionality.

5. Caching

Aggressive caching at the server, CDN, or browser level can serve old image URLs. Always clear all layers of cache after configuring the plugin. This includes object caching (Redis/Memcached), page caching, and CDN caches.

How to Verify What's Happening

Follow this test to diagnose the issue:

  1. Open your website in Chrome.
  2. Right-click and select Inspect to open DevTools.
  3. Go to the Network tab and check the Disable cache box.
  4. Reload the page.
  5. In the network list, find an image from your uploads directory. Look at the Type column. If it says webp, it's working! If it still says jpeg or png, the redirect failed.
  6. Click on the image request and check the Response Headers. If you see X-WebP-Convert-Status: direct or similar, it indicates the plugin's bypass is working but the rewrite rules are not.

If you've checked all these points and the issue persists, your specific server environment may have a unique configuration preventing the rules from working. In these cases, consulting your hosting provider's support is the most effective next step, as they have direct access to the server configuration logs.

Related Support Threads Support