WebP vs JPG

The short answer

For new photographic content delivered to a browser, WebP wins decisively over JPG. It produces 25–35% smaller files at visually equivalent quality, supports alpha transparency that JPG can't represent at all, and is rendered by every browser still under vendor support. The remaining case for JPG is universal compatibility outside the browser — email, marketplace uploads, social platforms that re-encode anyway, and tooling that hasn't caught up to WebP after fifteen years.

The decision is rarely either/or. The dominant pattern is <picture> with a WebP source and JPG fallback: capable browsers get WebP, the long tail gets JPG, and a single line of HTML routes correctly.

What each format is optimised for

JPG (more formally JPEG) was specified in 1992 to make photographic images small enough to share over modem connections. Every line of its design — chroma subsampling, DCT block transforms, quantisation — was tuned to discard visual information humans don't notice in continuous-tone imagery. It succeeded so comprehensively that it became the de facto photographic format on the internet for three decades.

WebP arrived in 2010 as Google's attempt to apply video-codec techniques to still images. Its lossy mode is based on VP8, the same codec that powers WebM video. Where JPG operates on independent 8×8 blocks, VP8's predictive coding lets blocks reference their neighbours — a fundamental advantage on the smooth-toned content where JPG has spent decades being good.

The result is a generational compression improvement on the same content type: 25–35% smaller files at the same visual quality. For more on the format itself, see WebP format overview; for JPG's structure, see JPG Format.

Where WebP wins

Photographic content for the web

The headline case. A 1200×800 photo at JPG q=85 might be 180 KB; at WebP q=80 the same photo lands around 110–130 KB with no visible difference. Across a typical page with eight images, that's roughly half a megabyte saved per page load.

The compounding effect on real-world traffic is meaningful. Sites that migrate JPG libraries to WebP consistently see Largest Contentful Paint improvements in the 200–500ms range — enough to move many pages from a yellow LCP into the green threshold.

Content with transparency

JPG can't encode an alpha channel. PNG was the only alternative for transparent photographic content until WebP arrived, and PNG was always wasteful for content with smooth gradients.

WebP solves this elegantly: it can encode RGB lossily and alpha losslessly in the same file. A product photo with a clean cut-out background — typically 800 KB as a PNG — drops to 80 KB as lossy WebP with lossless alpha, a 10× win with no visible quality loss.

Animated content

Not a JPG concern (JPG is single-frame), but worth flagging: replacing animated GIF with animated WebP is a separate win. Detail in WebP vs GIF.

Where JPG still wins

Universal compatibility outside the browser

Every email client renders JPG. Every social platform accepts JPG uploads. Every word processor, slide deck, document tool, embedded device, printer driver, and cloud-storage thumbnail viewer handles JPG natively. WebP's coverage in these contexts is improving but the long tail still has gaps.

Use JPG when the file will live outside the browser:

• Email attachments and newsletter imagery.
• Marketplace product photos (Etsy, eBay, Amazon listings) where re-encoding is happening anyway.
• Press releases and downloadable photo bundles.
• Open Graph and social-preview images, where some platforms still don't reliably handle WebP.
• Document embeds (Word, PowerPoint, PDF generation).

Universal tooling

A WebP file you receive may not open in older Lightroom installations, certain legacy CMS plugins, niche photo-management software, or hardware photo frames. A JPG file always opens. For collaborative workflows where the recipient's tooling is unknown, JPG removes friction.

Encoding speed

JPG encoders are simple and fast. WebP encoders at high effort (-m 6, the recommended setting for production output) can be 3–5× slower than JPG encoders at equivalent quality settings. For build pipelines that encode thousands of images, this matters. For per-image work, it doesn't.

File size in real numbers

Rough relationships, holding image content constant. Numbers vary by source content, but the relationships are stable:

The cut-out case is where WebP's transparency support produces the most dramatic win. There's no equivalent JPG approach — JPG simply cannot represent transparency.

The double-lossy problem

Encoding a JPG as lossy WebP applies two lossy passes to the same content. The first (the original JPG encoding) discarded information; the second (the WebP encoding) discards more from what remains.

In practice, at WebP q≥80, the double-lossy effect is invisible on typical content. The WebP encoder doesn't have much to discard from a high-quality JPG, and the output looks the same. Below q=80, artefacts can compound visibly.

Two viable patterns:

• Encode lossy WebP at q=80+. Smaller file than the source JPG, no visible quality loss in practice.
• Encode near-lossless WebP. Larger output but no risk of cumulative loss. Useful for content where artefacts matter (charts with text overlays, product photos under scrutiny).

The framework in Lossy vs Lossless Compression covers this in depth.

Quality settings

Both formats expose a quality factor with similar semantics but slightly different curves:

• JPG q=85 ≈ WebP q=78–80 at equivalent visual quality.
• JPG q=75 ≈ WebP q=70 for body imagery.
• JPG q=92 ≈ WebP q=85 for archival quality.

WebP's quality scale is somewhat more linear than JPG's. Above q=90 in either format, diminishing returns kick in hard — file size grows much faster than visible improvement.

For systematic encoder guidance, see WebP Compression Settings.

Browser support

WebP is supported in every browser still under vendor support: Chrome since 32, Firefox since 65, Safari since 14 (macOS Big Sur and iOS 14, both September 2020), Edge since 18. Global support sits above 97% of traffic.

The remaining ~3% — older iOS versions, IE11, legacy in-app webviews — is covered by the <picture> fallback pattern:

<picture>
  <source
    type="image/webp"
    srcset="/img/photo-800.webp 800w, /img/photo-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1200.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="..."
    width="1200"
    height="675"
    loading="lazy"
    decoding="async"
  />
</picture>

WebP-capable browsers use the <source>; others fall back to the <img>. No JavaScript required. Full coverage detail in WebP Browser Support.

Migration considerations

If you're moving an existing JPG library to WebP:

1. Keep the JPG originals. The <picture> fallback needs them. Disk is cheap; re-encoding is annoying.
2. Encode at WebP q=80 for body content, q=82 for hero imagery. Don't go below 75 except for thumbnails.
3. Use -m 6 (maximum encoder effort). Encoding happens once; serving happens millions of times.
4. Update HTML to use <picture> with the JPG fallback inside. Tools and CDNs can also do this server-side via Accept-header negotiation.
5. Verify image SEO in Google Search Console after a week of traffic. Google indexes WebP fine but file-name changes during migration can shift individual image rankings. See Image SEO Best Practices.
6. Audit your LCP image on each template type. The hero photo is usually the LCP element; converting it well is where most of the Core Web Vitals win comes from.

Recommendation

For new public-facing web content with photographic imagery, default to WebP with JPG fallback. Use lossy WebP at q=78–82 for body content, q=82–85 for heroes, q=65–72 for thumbnails.

For content distributed outside the browser, keep the JPG as the primary deliverable.

For migrating an existing JPG library, batch-convert at WebP q=80 with -m 6 encoder effort, ship as <picture> with the JPG fallback, and audit Core Web Vitals after a week of traffic to confirm the LCP win.

Common questions

Is WebP just "JPG but smaller"?

For lossy photographic content, roughly yes — same use case, better compression, broader feature set (transparency, animation). For lossless content (logos, icons), WebP also competes with PNG. WebP is more versatile than JPG; JPG is simpler and more universally supported.

Should I also ship AVIF on top of WebP?

For sites already shipping WebP, the marginal byte savings from also adding AVIF are typically 5–15%. Whether that's worth the additional encoding cost and the additional <source> element is a per-site decision. For new sites, the modern stack is AVIF → WebP → JPG fallback. See WebP vs AVIF and JPG vs AVIF.

Will my SEO suffer if I move from JPG to WebP?

No. Google indexes WebP and uses it in image search. Image SEO depends on alt text, file naming, structured data, and surrounding content — none of which change with format. See Image SEO Best Practices.

Can I convert WebP back to JPG without quality loss?

If the WebP was encoded lossily, the conversion preserves the WebP-quality version (with whatever lossy artefacts that introduced) as a JPG file. The JPG will introduce its own lossy artefacts on top, so the round trip degrades quality. If the original was JPG and you converted to WebP then back, you've stacked three lossy passes — visible artefacts are likely.

What about file-format SEO ranking?

Format alone is not a ranking signal. WebP doesn't rank higher than JPG. What matters is page performance (Core Web Vitals), which WebP improves by reducing payload size. The ranking benefit is indirect, via Core Web Vitals & Images.

Convert your images

• JPG to WebP — convert existing JPG library to WebP
• WebP to JPG — convert WebP back to JPG for distribution outside the browser

Further reading

• WebP format overview — technical detail on the WebP container and codecs
• JPG Format — JPG's compression pipeline and current relevance
• WebP Optimisation — broader performance walkthrough
• WebP Compression Settings — encoder parameter reference
• Lossy vs Lossless Compression — mode selection
• Core Web Vitals & Images — performance impact