WebP is often presented as a smaller replacement for JPEG and PNG. You convert the WordPress media library and discover that some .webp files are larger than the originals.
That does not mean the format is broken. It means the comparison includes more than the extension. Dimensions, source compression, encoder quality, transparency and metadata determine the result.
Do not publish the converted file until you have compared the actual delivered bytes and visual quality.
Confirm you are comparing the same image variant
WordPress normally generates several sizes. The original JPEG might be 1200 pixels wide while the WebP you found is the full 3000-pixel upload.
Compare:
- pixel width and height;
- crop;
- colour profile;
- alpha/transparency;
- metadata;
- quality setting;
- exact WordPress size name.
Use the browser Network panel to identify the file selected on the page. The largest file on disk may not be the one visitors receive.
A well-compressed JPEG is already efficient
A JPEG exported carefully for the web can be difficult to beat by a large margin. If the conversion tool uses a high WebP quality value to preserve every detail, the new file may grow.
The correct comparison is not:
WebP quality 90 versus JPEG quality 70.
It is:
Which file gives acceptable visual quality at the required dimensions with fewer transferred bytes?
Quality scales are not equivalent between encoders.
Lossless WebP can be much larger than a photographic JPEG
Some plugins choose lossless WebP for files with transparency or certain PNG/JPEG settings. Lossless compression is rarely the right comparison for a photograph already stored as lossy JPEG.
Inspect the conversion mode. For photographic content, test lossy WebP at several qualities. For flat artwork, logos or screenshots, compare lossless and lossy results visually.
Never convert a transparent source to JPEG merely to reduce size if the transparency is required by the design.
Dimensions matter more than format in many failures
A 2400-pixel WebP can be larger than an 800-pixel JPEG while still being efficient per pixel.
Before tuning the encoder, fix the requested dimensions:
- generate suitable WordPress sizes;
- ensure
srcsetincludes them; - define accurate
sizes; - prevent CSS backgrounds from using the original upload unnecessarily.
Format optimisation cannot compensate for delivering nine times the required pixel area.
Metadata and colour profiles can survive conversion
Some tools preserve EXIF, XMP or colour profiles. Others remove them. This can account for unexpected size.
Use an image inspection tool to compare metadata. Decide what is required:
- orientation should be baked correctly;
- colour should remain acceptable;
- copyright metadata may be intentionally retained;
- GPS and camera data may need removal for privacy.
Do not strip metadata blindly when it carries a legitimate requirement.
Encoder implementations differ
The same source and nominal quality can produce different results in:
- a WordPress plugin;
- ImageMagick;
- a hosting optimisation service;
- a CDN;
- a desktop editor.
Record the tool and version. Test a representative sample rather than converting the entire library repeatedly.
With ImageMagick, a controlled test might be:
magick source.jpg -strip -quality 78 output.webpThis is an example starting point, not a universal setting. Work on a copy, confirm the installed command and inspect the output before replacing anything.
WordPress may store both files but serve the original
Generating WebP does not prove visitors receive it.
In the Network panel, verify:
- request URL;
Content-Type;- transferred bytes;
- response headers;
- selected image candidate.
Some systems rewrite the URL. Others use <picture>. A CDN may negotiate format through the Accept header.
Check that cache variation is correct. Serving WebP to a client that did not request or support it can cause broken images on older environments.
Repeated conversion can degrade the source
Do not create a new JPEG from an already compressed JPEG and then convert that derivative again. Repeated lossy encoding can add artefacts while the file remains large.
Keep the best available original as the source of future variants. If WordPress has already replaced it, retrieve the approved master from backup where possible.
Compare visual quality at rendered size
Open the JPEG and WebP beside each other at:
- 100% pixel view;
- actual desktop display size;
- actual mobile display size;
- high-density display if important.
Look for:
- block artefacts;
- smeared hair or foliage;
- banding in gradients;
- halos around text;
- colour shifts;
- damaged transparency.
The smallest file is not the winner if it visibly weakens product trust.
Product images need zoom-aware decisions
WooCommerce thumbnails and product zoom do not have the same requirement. A thumbnail can use a compact file; the zoom image needs more detail.
Ensure the product gallery references an appropriate large variant without forcing every listing page to download it. Test variation images and retina displays.
Do not globally lower quality until product detail has been approved.
Transparency and screenshots need a different comparison
An interface screenshot or graphic with sharp text behaves differently from a photograph. Lossy WebP may blur small lettering, while lossless WebP can remain larger than a carefully indexed PNG.
For transparent artwork, compare:
- alpha edge quality;
- colour fringing on light and dark backgrounds;
- lossless WebP;
- lossy WebP with alpha;
- optimised PNG;
- the actual CSS display size.
Do not flatten transparency against white unless the image will always appear on white. Dark backgrounds, hover states or future design changes can expose a visible box.
Screenshots often contain large areas of flat colour and small text. Crop unnecessary browser chrome before encoding and avoid scaling them through several intermediate editors. The clean source and correct dimensions may save more bytes than switching format.
Check whether the “larger” file is cached differently
A smaller JPEG with poor cache headers can still transfer more often than a larger WebP cached for a long period. File size and delivery policy both matter.
Version immutable assets or ensure WordPress generates new URLs when images change. Avoid year-long caching for a file overwritten under the same URL.
Use a representative conversion matrix
Choose samples:
- photograph;
- product image;
- screenshot;
- transparent graphic;
- gradient;
- existing highly compressed JPEG.
For each, record dimensions, source size, output size, encoder, quality and visual approval. Select rules per class rather than one global percentage.
Avoid deleting originals too early
Keep the source and a database/files backup until:
- WebP delivery is verified;
- responsive variants work;
- visual quality is approved;
- rollback is tested;
- old references are understood.
Deleting the only original can turn a reversible optimisation into permanent media loss.
Evidence for an image-format assessment
Provide sample source/output files, WordPress URL, rendered dimensions, conversion tool/settings and the browser-selected request. Do not include private media that is not authorised for review.
If WebP images are larger than the original JPEGs, we can compare equivalent variants, correct sizing and tune the conversion by image type. The goal is fewer delivered bytes at approved visual quality—not a collection of files with a modern extension.