You've already done the "easy" optimization — converting your JPEGs and PNGs to WebP — and your images did get smaller. But your page speed report is still flagging them, or your CDN bill hasn't moved as much as you expected, and you're left wondering whether WebP has more to give or whether you've already hit the floor.
It has more to give. WebP's default export settings in most tools are tuned for a safe, general-purpose result — not the smallest possible file. Once you understand the handful of settings that actually control WebP's output size, squeezing out another 10-40% is usually just a matter of changing a few numbers, not re-shooting or re-designing anything.
To reduce WebP file size further, lower the quality setting into the 75-85 range for photos, switch to the slowest/most thorough compression method your tool offers, use near-lossless instead of true lossless for graphics, resize images to their actual display dimensions, and strip unused metadata. Combined, these typically cut another 10-40% off an already-converted WebP file with no visible quality loss.
What actually controls WebP file size?
WebP's file size isn't one dial — it's the result of several independent settings stacking on top of each other. Most default exports only touch the first one, which is why there's usually room left to cut:
- Quality setting (0-100) — for lossy WebP, this is the biggest lever. It controls how much detail the encoder is allowed to discard. Most tools default to a "safe" 80-90, but the visible difference between 85 and 95 is minimal while the size difference is not.
- Compression method (0-6) — a separate setting from quality, this controls how exhaustively the encoder searches for the smallest possible representation at that quality. Higher methods take longer to encode but produce meaningfully smaller files for identical visual output.
- Lossless vs near-lossless — true lossless preserves every pixel exactly, but near-lossless applies light, imperceptible preprocessing first, which lets the lossless compressor work more efficiently on graphics and screenshots.
- Pixel dimensions — a file's raw dimensions determine how much data exists before compression even starts. An oversized source image inflates the file regardless of how aggressive your compression settings are.
- Metadata — EXIF data, color profiles, and XMP tags carried over from a camera or design tool add bytes that have zero effect on how the image looks on a web page.
Change any one of these and the file shrinks a little. Change all of them together, and the gains compound — often taking an already-converted WebP file down by another third.
Why squeezing WebP further matters
Converting to WebP gets you most of the win in one step, but the extra effort of tuning settings pays off in ways that scale with how many images you're serving:
- Compounding savings at scale. A further 15-20% reduction across a product catalog or media library adds up to real bandwidth and storage savings that a single image would never reveal.
- Better Core Web Vitals. Largest Contentful Paint is directly sensitive to the size of your largest visible image — shaving extra kilobytes off hero images and above-the-fold graphics has an outsized effect on that metric specifically.
- Faster experience on constrained connections. The users who benefit most from tighter compression are exactly the ones on slow mobile connections where every extra kilobyte is felt.
- Headroom without new tooling. Because these are settings, not a different format or pipeline, there's no migration cost — it's the same WebP file, just encoded more deliberately.
Step-by-step: how to reduce WebP file size
- Resize to actual display dimensions first. Before touching any compression setting, check that the image's pixel dimensions match where it's actually displayed. An image shown at 800px wide but exported at 2400px wastes roughly nine times the pixel data before compression even begins.
- Lower the quality setting into the 75-85 range. For photographs, this range is nearly always visually indistinguishable from 95-100 while producing noticeably smaller files. Test a couple of values and compare side by side rather than assuming higher is always safer.
- Switch to the slowest compression method available. Most encoders expose a method or effort setting from 0 (fast) to 6 (slowest, most thorough). For final delivery assets, always use the highest setting — encoding time is a one-time cost, but the smaller file is served to every visitor.
- Use near-lossless instead of true lossless for graphics. If an image doesn't need bit-for-bit pixel accuracy — most logos, icons, and UI screenshots don't — near-lossless mode typically shrinks the file another 20-30% with no visible change.
- Strip metadata on export. Turn off EXIF, XMP, and embedded color profile data unless a specific workflow depends on it. This is a small but free win, especially on images exported directly from a camera or design tool.
- Re-check visually at 100% zoom, not just thumbnail size. Aggressive settings can look fine in a thumbnail and show artifacts at full size. Spot-check a few representative images at their actual display size before rolling settings out broadly.
- Batch apply once you've found your settings. Once you've settled on a quality level and method for a given image type (photos vs. graphics), apply it consistently across the batch rather than tuning every image individually.
Common mistakes that keep WebP files large
1. Leaving lossless mode on for photographs
Lossless WebP is built for graphics and transparency, not photos. Applying it to a photograph produces a file several times larger than lossy WebP at visually identical quality — check which mode your export tool defaults to before assuming it's optimized.
2. Trusting the default quality setting
Many design tools and CMS plugins default to a conservative quality of 90 or higher "to be safe." That default leaves size on the table for the vast majority of images, where 75-85 looks identical but weighs meaningfully less.
3. Compressing before resizing
Running compression settings on an image that's still oversized in pixel dimensions treats the symptom, not the cause. Always resize to the actual display size first — no amount of quality tuning recovers what oversized dimensions waste.
4. Re-compressing an already lossy-compressed image repeatedly
Every lossy re-encode compounds quality loss, similar to re-saving a JPEG multiple times. Always compress from the original source or a lossless master, never from a previously compressed lossy WebP.
Real-world examples
These are representative results from re-compressing already-converted WebP files using the techniques above:
The biggest single win is almost always dimensions, not compression settings — but stacking quality, method, near-lossless, and metadata stripping on top of a correctly sized image is where the extra 10-40% comes from.
Quality setting vs file size comparison table
Approximate results for a typical photograph exported as lossy WebP at different quality settings, holding dimensions constant.
| Quality setting | Relative file size | Visual result | Recommended use |
|---|---|---|---|
| 95-100 | Largest | No visible gain over 85 | Rarely needed for web delivery |
| 85-90 | Large | Visually indistinguishable from 100 | Common default — safe but not optimized |
| 75-85 | Balanced | No visible artifacts at normal viewing distance | Recommended for most photos |
| 60-70 | Small | Minor softening, visible on close inspection | Thumbnails, low-priority images |
| Below 50 | Smallest | Visible artifacts, blockiness | Not recommended for photos |
Compress your WebP images right now — free
The Rebrixe Image Converter runs entirely in your browser. Fine-tune quality and re-compress WebP files, or convert from JPEG/PNG directly at your preferred settings — your images are never uploaded to a server. No account, no file size limit, no watermarks.