The short answer: on image quality per byte, WebP beats JPG by a wide margin. On compatibility, JPG is untouchable — it opens on every device, in every application, at every print shop on the planet. So the answer to "which is better" is a question back: where is the image going? The web, under your control: WebP. Anywhere unknown: JPG. Here is the technical case for both halves of that answer.
The compression: 1992 vs 2010
JPEG's core trick dates to 1992 (the history of JPG has the full story). The image is cut into 8×8 pixel blocks, each block is run through a discrete cosine transform into frequencies, and a quantizer throws away the high-frequency detail your eyes barely register. Color resolution is halved on the same reasoning. It was brilliant engineering for the era of dial-up, and it has not fundamentally changed since.
Lossy WebP is VP8's intra-frame coding, released by Google in 2010 (the birth of WebP covers how it came out of video compression work). The philosophy is the same — keep what eyes notice, discard the rest — but the machinery is eighteen years newer. VP8 predicts each block from its neighbors before transforming the leftover difference, uses a more efficient entropy coder, and adapts quantization strength across regions of the image instead of applying one global setting.
The measurable result: at matched visual quality, WebP files come out roughly 25 to 35 percent smaller than JPG. Both formats are lossy — every save discards information — and our explainer on lossy vs. lossless compression covers what that means for editing either one.
The gap widens as you push compression harder. At high quality both formats look fine. Crank the quality down and JPG's 8×8 blocks surface as visible checkerboard artifacts, while WebP degrades into smoothness rather than blocks — still degraded, but a quieter kind of degraded. For thumbnails and preview images, where the bytes matter most and scrutiny is lowest, that behavior is worth more than the headline percentage.
The size table
Same photo, matched subjective quality:
| Photo | JPG | WebP (lossy) |
|---|---|---|
| 12 MP, full quality | ~3.4 MB | ~2.3 MB |
| 1920×1080, web delivery | ~450 KB | ~300 KB |
| Thumbnail, 400 px wide | ~35 KB | ~24 KB |
A third off every image on a page adds up fast — that is the entire reason websites adopted WebP so aggressively. Multiplied across a grid of product images, it is the difference between a two-second load and a three-second load on a mid-range phone connection.
What WebP has that JPG never will
JPG's format is frozen; WebP's container had room to grow. Two features matter:
Alpha transparency. Lossy WebP carries a separately encoded alpha channel, so a photo can sit on a transparent background. JPG has no alpha at all — transparency flattens to a solid color on save.
Animation. WebP does animated images with full color and alpha, which made it a practical GIF replacement. An animated JPG is not a thing.
Neither matters for a plain photograph. Both matter the moment a website needs a transparent product cutout or a short looping clip.
JPG's moat: it works everywhere, forever
JPG has been readable since the early nineties. Every camera shoots it. Every phone, printer, TV, digital photo frame, hospital imaging kiosk, and twenty-year-old CMS reads it. Upload forms that reject everything else accept JPG. That is not a feature you can benchmark — it is three decades of accumulated support, and no format spec can replicate it.
WebP has rendered in every modern browser for years, but outside the browser the support thins out fast: older image editors, aging CMSs, print pipelines, embedded devices. We mapped the same gap from the graphics side in WebP vs PNG, and from the lossy-versus-lossless side in JPG vs PNG.
Which one when
| Where the image is going | Use | Why |
|---|---|---|
| A website you control | WebP | ~30% smaller at equal quality |
| Email, messaging, unknown recipients | JPG | opens for everyone, no explanation needed |
| JPG | print pipelines expect it | |
| Upload forms you do not control | JPG | many still reject WebP |
| Logos, cutouts, anything transparent | WebP | JPG cannot do alpha |
| Long-term archive of a master | Neither — keep the original, or go lossless | both formats throw data away |
When you need to convert
If a website handed you WebP files that need to work somewhere older, WebP to JPG converts them locally in your browser — batch and ZIP download included, nothing uploaded; the walkthrough is in how to convert WebP to JPG. Going the other way, JPG to WebP shaves a third off photos before they go on a page.
The rule that falls out of all of this: shoot and send in JPG, publish in WebP, and convert at the boundary between the two worlds.