If you've touched a frontend performance audit in the last few years, you've probably been told to "just convert everything to WebP." It's solid advice most of the time—but not always, and treating it as a blanket rule can quietly cause problems you won't notice until a designer or a client asks why their logo looks slightly off.
Here's a more honest breakdown of where WebP actually helps, where it doesn't, and how to handle the conversion without turning it into a manual chore.
What WebP actually gets you
WebP was built by Google specifically to solve the "images are too heavy" problem. Compared to JPG, lossy WebP typically shaves off 25–35% in file size at a similar visual quality. Compared to PNG, lossless WebP can cut file size by roughly 20–50%, which matters a lot for icons, screenshots, and UI graphics.
It also does a few things JPG and PNG can't do together:
- Alpha transparency with lossy compression. PNG gives you transparency, JPG gives you small lossy files—WebP gives you both at once.
- Animation support. A WebP animation is usually a fraction of the size of the equivalent GIF.
- One format, two modes. You can pick lossy or lossless per image depending on whether it's a photo or a flat-color graphic.
For a typical marketing site, blog, or e-commerce catalog, switching hero images and product photos to WebP is close to a free win on page weight and Core Web Vitals.
Where it gets messier
The catch isn't really about browser support anymore — Safari, Firefox, and Chrome have all supported WebP for years, so that argument is mostly outdated. The real friction shows up elsewhere:
Print and prepress workflows. WebP has no place in a print pipeline. If a file is headed to a printer or needs CMYK color handling, you're back to TIFF or high-res PNG.
Editing round trips. Some older versions of design tools handle WebP awkwardly on import, and re-saving a WebP repeatedly (lossy mode) degrades quality the same way repeatedly saving a JPG does.
Email clients. A lot of email clients still render WebP inconsistently or not at all. If you're building an email template, JPG and PNG remain the safer default.
Extreme high-fidelity needs. For product photography where every pixel of detail matters — think jewelry, textiles, or medical imaging — lossless PNG or even TIFF can still outperform WebP's handling of fine texture, depending on the compression settings used.
Team friction. If your team, client, or CMS plugin ecosystem doesn't fully support WebP uploads, forcing the format can create more support tickets than it saves in bandwidth.
A quick size comparison
To make the "25–35% smaller" claim less abstract, here's a rough sense of what that looks like on a typical 1920×1080 hero photo, exported at comparable visual quality:
| Format | Approx. file size | Transparency | Animation |
|---|---|---|---|
| JPG (quality 80) | ~180–220 KB | No | No |
| PNG-24 | ~900 KB–1.4 MB | Yes | No |
| WebP (lossy, quality 80) | ~120–150 KB | Yes | Yes |
| WebP (lossless) | ~400–600 KB | Yes | Yes |
Exact numbers vary a lot by image content (a flat-color illustration compresses very differently from a noisy photo), but the pattern holds consistently: lossy WebP undercuts JPG, and lossless WebP undercuts PNG, usually by a wide margin.
Converting with the CLI
If you want to test this yourself, Google's cwebp encoder is the fastest way to check real numbers on your own images:
# Basic lossy conversion, quality 80
cwebp -q 80 input.jpg -o output.webp
# Lossless, for graphics/screenshots
cwebp -lossless input.png -o output.webp
# Batch convert a folder
for f in ./images/*.png; do
cwebp -q 80 "$f" -o "./webp/$(basename "${f%.png}").webp"
done
Run cwebp with -q values between 70 and 85 for photos—that range is usually the sweet spot where file size drops noticeably but compression artifacts stay invisible to the eye.
A practical rule of thumb
- Use WebP for web-facing photos, hero banners, product thumbnails, and any UI graphic where file size directly affects load time.
- Keep PNG for anything needing pixel-perfect transparency edges, screenshots used for documentation, or assets headed into design tools with shaky WebP support.
- Keep JPG for email attachments, legacy CMS constraints, or anywhere WebP support is explicitly unverified.
- Avoid WebP entirely for print production.
In short: WebP is a great default, not a universal one.
Handling the conversion without the busywork
Once you've decided which assets should move to WebP, the actual conversion is the boring part—and it's worth automating rather than doing by hand.
If you're already in a build pipeline, a CLI encoder or a Sharp-based build plugin lets you batch-convert during your build step, so nothing extra lands in your repo.
For quick one-off conversions—say, a designer hands you a folder of PNGs and you need WebP versions fast—it's often easier to skip the CLI entirely. I usually reach for a browser-based WebP converter for this: drag in a batch of files, no install, no account, and it handles the "just convert these 40 files" case in about the time it'd take to configure a script.
The format choice matters more than the tool you use to get there—but having a fast, no-friction converter on hand means the "Should this be WebP?" decision doesn't turn into a 20-minute detour every time.
Bottom line
WebP earns its reputation for a reason, but "always WebP" is a shortcut, not a rule. Know your output—web, print, email, or archival—and let that decide the format, not habit.
Top comments (0)