ShortPixel WebP not working on WordPress usually points to one of two failures: the WebP file was never created, or it was created but not delivered. Those failures require different fixes. A generation problem is solved in the Media Library or ShortPixel optimization settings. A delivery problem is solved in page markup, server rules, caching, a CDN, or a conflicting optimization tool.
Do not judge the format from the image URL alone. A URL that ends in .jpg can return image/webp when delivery uses content negotiation or an image CDN. Conversely, finding a .webp file in the uploads directory does not prove that visitors receive it. The response headers and the browser’s selected resource are the reliable evidence.
Start with one controlled image
Choose one image that appears on a public page and note its original URL. Use a normal content image rather than a CSS background, slider, or externally hosted asset for the first test. Open the page in an incognito session, launch Developer Tools, switch to Network, reload the page, and filter the requests by “Img.” Click the chosen request and record four items:
- the final request URL after any redirects;
- the response
Content-Type; - the Initiator or page element that requested it; and
- whether the response came from the browser, WordPress cache, hosting cache, or CDN cache.
If Content-Type is image/webp, delivery works for that request even if the visible URL still ends in JPEG or PNG. If the response remains image/jpeg or image/png, continue through the checks in order. Changing several settings at once makes the cause harder to identify.
1. ShortPixel WebP not working: verify what the browser received
Inspect the image request in the Network panel rather than relying on “View Source,” a filename, or a performance report. With <picture> markup, browsers evaluate the available <source> entries, select a compatible candidate, and retain the nested <img> as a fallback. MDN documents this selection process in its HTML picture element reference.
In the Console, selecting the image element and checking its currentSrc property can reveal which candidate won. MDN defines currentSrc as the URL of the image selected by the browser. For server-level replacement, it may still show the original extension, so confirm the response Content-Type as well. Test with cache disabled while Developer Tools is open, then repeat in a fresh private window to avoid mistaking a local cached response for the current server behavior.
2. Confirm that a WebP counterpart exists for the requested size
WordPress commonly creates several image sizes from one upload. The full-size file may have a WebP counterpart while the specific thumbnail requested by the page does not. Identify the exact filename and dimensions in the Network panel, then check that same derivative in the Media Library, ShortPixel details, or the corresponding uploads directory.
A successful optimization message for the parent attachment is not enough. The page might request a size generated later by a theme or plugin. If only one derivative fails, regenerate or optimize that derivative instead of repeatedly changing global delivery settings. If no sizes have WebP counterparts, move to the generation settings in the next check.
3. Make sure WebP creation was enabled before optimization
ShortPixel Image Optimizer creates next-generation copies during optimization. If the library was optimized before “Create WebP Images” was enabled, switching the option on does not retroactively create every missing file. ShortPixel’s official instructions for an already optimized library direct users back to Media > Bulk ShortPixel, where the Media Library and WebP creation option can be selected for a new calculation and run.
Before a bulk action, test the process on the controlled image and its thumbnails. Confirm that the expected files appear, then repeat the browser request. This separates a creation failure from a delivery failure without spending time or optimization credits on unrelated attachments.
4. Check whether ShortPixel intentionally skipped the conversion
A missing WebP is not always an error. ShortPixel states that it does not store a generated WebP or AVIF when that result is more than 5% larger than the source. The rule is intended to avoid serving a heavier file and consuming a credit for no size benefit. The vendor documents this behavior in its conversion troubleshooting guidance.
This can happen with an already efficient JPEG, a small graphic, or a source that does not benefit from another conversion. Compare the original and candidate sizes before overriding the behavior. Serving a larger WebP merely to make every request use the same format works against the performance goal.
5. Confirm that one delivery method is enabled
File creation and browser delivery use separate ShortPixel controls. A WebP counterpart can exist without any mechanism telling the browser or server to use it. In ShortPixel Image Optimizer, review the WebP/AVIF & CDN section and confirm the intended method: picture markup, server-level replacement through .htaccess, or the ShortPixel CDN.
Each method changes a different layer. Picture delivery rewrites HTML. The .htaccess method keeps the original image URL and lets the web server choose the alternative response. CDN delivery rewrites requests to an image delivery service. ShortPixel’s delivery-method comparison recommends testing because hosting, themes, and third-party plugins differ.
Enable only the method you intend to test. Two tools rewriting the same image request can produce inconsistent markup, double CDN URLs, redirect chains, or cache entries that no longer match browser capabilities.
6. If using picture markup, inspect the final DOM
Open the Elements panel after the page has rendered. A working picture-based setup should offer a WebP source and retain an <img> fallback. Check the final DOM, not only the original HTML response, because a lazy-loading plugin, slider, page builder, or JavaScript component may replace the element after ShortPixel processes it.
ShortPixel’s picture-delivery troubleshooting guide lists common conflicts: background images, JavaScript-loaded images, lazy loading, page builders, nonstandard upload folders, and stale caches. It also notes that adding a <picture> wrapper can break CSS selectors that expect the image to be a direct child.
Temporarily disable one suspected rewriting feature, purge its cache, and test the same image again. If the WebP source appears, restore the feature and choose which tool should own image rewriting. Do not permanently disable unrelated performance features based on a single unpurged test.
7. If using server rules, test Accept and Vary behavior
Server-level delivery depends on the request and response headers. A modern browser normally advertises acceptable image formats in the Accept header. The origin then chooses a representation, and caches need to distinguish variants correctly. MDN’s HTTP content negotiation guide explains how Accept guides the choice and how Vary tells caches which request header influenced the response.
Compare two command-line requests to the exact image URL: one that advertises image/webp and one that does not. Record the status, Content-Type, Vary, cache headers, and final URL. If both requests always return JPEG, the rewrite may be absent, unreadable, unsupported by the server, or bypassed by a proxy. If both always return WebP, fallback behavior and cache separation need review.
The .htaccess option applies to Apache-compatible configurations. NGINX’s WordPress guidance states that NGINX does not support .htaccess files. Managed hosts may also restrict rewrites. In those environments, use a host-supported NGINX rule, picture delivery, or a compatible CDN rather than repeatedly saving an Apache-only option.
8. Purge every cache layer in the request path
Old page HTML can omit the new <picture> markup, while an old image cache can keep returning JPEG from the original URL. Clear caches from the innermost transformation layer outward: CSS or JavaScript optimization, WordPress cache plugin, host or server cache, CDN, and finally the browser. That order follows ShortPixel’s cache-clearing checklist.
Purge only the test page and image first when your tools support targeted invalidation. Then retest with a private browser window and cache disabled in Developer Tools. A cache purge is not proven by a success notice; confirm that the next response has a new cache status or age and the expected content type.
9. Remove duplicate image optimization and CDN ownership
List every component that can alter image URLs or formats: ShortPixel Image Optimizer, ShortPixel Adaptive Images, a cache plugin, a theme optimizer, a host optimization layer, and the CDN. Assign one owner for format conversion and delivery during the test. Disable only the overlapping WebP or image-CDN feature in the other components.
For a CDN that caches negotiated image variants, the cache key must separate compatible representations. Cloudflare documents a dedicated Vary for Images feature that maps source extensions to supported image formats and caches those variants separately. Do not assume that forwarding an Accept header automatically creates correct cache behavior on every CDN plan or configuration.
After simplifying the path, test from origin to edge one layer at a time. If the origin returns WebP but the CDN returns JPEG, the WordPress plugin is no longer the primary fault. If the origin itself returns JPEG, fix generation or origin delivery before changing edge settings.
10. Test assets that bypass the normal Media Library path
A standard uploaded image may work while a hero, logo, slider, or CSS background still fails. Check where each problem asset comes from. Theme and plugin directories, custom upload folders, external domains, inline CSS, generated JSON, and JavaScript components may bypass the hooks used by a local picture-markup method.
For local files outside the normal uploads directory, add only supported custom media folders and optimize them through the appropriate ShortPixel feature. For CSS backgrounds or JavaScript-generated URLs, use a delivery method that can see those requests or configure the relevant Adaptive Images replacement area. Externally hosted images need control of, or authorization for, that source domain; a local plugin cannot create files on an unrelated server.
When testing ShortPixel Adaptive Images, repeat the same test at least twice before classifying a one-time miss as a persistent failure. ShortPixel’s Adaptive Images troubleshooting guidance says that a single speed test can produce an inaccurate conclusion because of how the service works. Compare the response URL, content type, and cache status across the repeated requests.
A reliable fix leaves evidence at every layer
The issue is resolved only when the requested derivative exists, the selected delivery method is active, the final DOM or server rule points to a valid alternative, caches separate or refresh the response correctly, and the browser receives image/webp. Keep the test image, request URL, response headers, and the single setting change together as a small diagnostic record.
If ShortPixel WebP not working remains the result after these checks, keep the evidence from the first failing layer and change only that layer before testing again. This avoids masking the original fault with unrelated cache, CDN, or plugin changes.
Once the controlled image passes, repeat the test with a normal inline image, a responsive thumbnail, and one special case such as a background or slider image. If you still need to choose between modern formats rather than troubleshoot delivery, compare their compatibility and workflow tradeoffs. For initial configuration, use the separate plugin setup walkthrough.