Updated: August 1, 2026
Short answer: Use WebP as a strong candidate for modern website photos, but keep JPEG when an upload system, email client, or older application needs it. Convert from the original, compare both at the displayed size, and use responsive variants because pixel dimensions often matter more than the extension.
WebP and JPEG are not competitors in every situation. WebP is primarily a web delivery format with lossy, lossless, transparency, and animation support. JPEG is a mature lossy photo format that works in almost every browser, editor, office workflow, email client, and upload form. A good website can use both without asking the visitor to choose.
WebP vs JPEG: Quick Decision Table
| Situation | Better starting choice | Keep or serve as fallback | Reason |
|---|---|---|---|
| Modern website photograph | WebP | JPEG | WebP often reaches similar visual quality with fewer bytes. |
| Email newsletter or attachment | JPEG | Original source | Client compatibility is more important than a small web saving. |
| Screenshot with small text | Lossless WebP or PNG | PNG | Lossy JPEG can soften text and thin lines. |
| Legacy upload form | JPEG | Original source | Some systems validate the extension or MIME type. |
| Transparent web asset | WebP or PNG | PNG | WebP supports alpha; PNG remains broadly accepted. |
| Print or editing master | JPEG at an appropriate quality, TIFF, PSD, or RAW | Keep the master | A web delivery copy should not become the editable source. |
What Google’s WebP Study Actually Shows
Google’s published study compared WebP and JPEG at similar SSIM values using defined image sets and encoders. It reported an average WebP saving of 25–34% compared with JPEG at equivalent SSIM. The study is useful because it explains the comparison method, but it is not a guarantee for every photo or for every current encoder. Read the WebP compression study before reusing the percentage in a benchmark claim.
The practical lesson is not “WebP is always 30% smaller.” It is “compare formats at a similar visual target.” A noisy night photo, a flat product shot, a screenshot, and a previously compressed JPEG will behave differently. A file can also become larger if you convert a tiny or already optimized image without checking the output.
When WebP Is a Good Choice
WebP is a good candidate for:
- blog photos and article illustrations;
- product images delivered through a website or CDN;
- thumbnails and gallery images;
- transparent cut-outs when alpha edges survive the conversion;
- graphics that need lossless compression but can use a modern web format.
Google’s WebP documentation describes both lossy and lossless modes, transparency, and animation. For photos, use lossy WebP and compare the visual result. For a logo or screenshot, use lossless WebP if it actually produces a smaller file than the optimized PNG.
When JPEG Is Still the Right Choice
JPEG remains the safer choice when:
- a third-party upload form accepts only JPEG or rejects unknown extensions;
- the asset is going into an email client with uncertain WebP support;
- the image must open in older desktop software or a legacy application;
- you need a simple final fallback in a
<picture>element; - the image is already small and a conversion would add operational complexity.
JPEG is not automatically low quality. A correctly sized JPEG at a moderate quality can be better than an oversized WebP that takes longer to decode or is rejected by the destination. Optimize the file that users can actually receive.
A Safe JPEG-to-WebP Workflow
- Keep the original JPEG untouched.
- Identify the largest CSS width at which the image appears.
- Export a WebP near the needed pixel dimensions; do not rely on CSS to shrink a camera-resolution source.
- Compare the WebP with the JPEG at the real display size and at 100%.
- Inspect faces, gradients, product edges, text, and dark areas.
- Check the WebP file size and the page’s delivered request.
- Keep JPEG as a fallback if any important client or destination needs it.
For responsive delivery, generate more than one width:
<picture>
<source
srcset="photo-640.webp 640w, photo-960.webp 960w, photo-1280.webp 1280w"
type="image/webp"
/>
<img
src="photo-1280.jpg"
srcset="photo-640.jpg 640w, photo-960.jpg 960w, photo-1280.jpg 1280w"
sizes="(max-width: 700px) 100vw, 760px"
width="1280"
height="853"
alt="A ceramic cup on a wooden table"
/>
</picture>
The <picture> element handles format fallback. srcset and sizes handle pixel-density and layout choices. The two solve different problems and should not be treated as interchangeable.
Quality Settings Are Not Portable
Quality 80 in one encoder is not guaranteed to match quality 80 in another. Chroma subsampling, quantization tables, metadata, progressive scans, and encoder version all affect the output. Use a quality value as a starting point, not as a claim about the final result.
If a WebP looks soft, do not immediately raise quality on a source that is already blurry. Check the source dimensions and whether it has been compressed multiple times. If a JPEG looks sharper but much larger, compare at the size users see; zooming to 400% can exaggerate differences that do not matter in the layout.
WebP and JPEG for SEO
A format does not replace image accessibility or page quality. Use meaningful alt text for informative images, keep important text as HTML when possible, set dimensions to prevent layout shifts, and make the main image discoverable. A smaller WebP can help the download phase, but an oversized WebP or a late-discovered hero can still create a poor experience.
Pixel Dimensions Usually Matter More Than the Extension
Suppose a content column renders an image at 760 CSS pixels but the server sends a 4,000-pixel source. Converting that file from JPEG to WebP may save bytes, but the browser is still receiving many more pixels than the layout needs. Create derivatives close to the actual display widths and let srcset and sizes select among them.
For a hero image, the largest useful width may be one or two device-pixel ratios above the CSS width. For a small card, sending the hero-sized asset is wasteful. Test the page on a narrow connection and inspect the actual request in DevTools; the filename alone cannot tell you whether the right candidate was selected.
Choose by Delivery Destination
| Destination | Practical choice | Verification |
|---|---|---|
| Public article page | WebP with JPEG fallback | Inspect Content-Type, request size, and LCP. |
| Product catalog | WebP or AVIF from a tested CDN | Check zoom, color, and variant selection. |
| Newsletter | JPEG or PNG | Test Gmail, Outlook, Apple Mail, and image blocking. |
| Upload portal | The format the portal accepts | Download and reopen the submitted copy. |
| Design handoff | Original JPEG, PNG, TIFF, PSD, or source file | Keep delivery derivatives separate. |
This destination-first approach prevents a common failure: optimizing for a browser benchmark and then discovering that the CMS, email client, or customer upload form rejects the output.
How to Migrate Without Breaking Existing URLs
Do not replace every JPEG URL in one step without a rollback. Keep the originals, generate WebP derivatives, and change delivery at the template or CDN layer. Check cached pages, social previews, image sitemaps, structured data, lazy-loaded attributes, and any code that assumes a .jpg extension.
After publishing, test a representative page with JavaScript disabled where possible, inspect the request waterfall, and open the fallback URL directly. If a browser receives the wrong MIME type or a stale cache returns a WebP body under a JPEG response, the migration is not ready regardless of the file-size result.
Common Mistakes
- Converting JPEG to WebP without checking whether the file became smaller.
- Re-encoding a low-quality JPEG instead of using the original source.
- Using the same quality setting for every image.
- Serving a single desktop-sized WebP to mobile users.
- Removing JPEG fallbacks from email or third-party upload workflows.
- Calling a format “better for SEO” without measuring the actual page.