WebP vs JPEG: Which Should You Use, and When JPEG Still Wins

WebP produces smaller files than JPEG for almost all web imagery. On the test photograph it produced 27.0 KB against 41.1 KB from MozJPEG at the same nominal quality, with marginally higher measured fidelity — 34% smaller. Against the libjpeg-turbo baseline that most tools ship, the gap was 60%.

The advantage is not universal. On a synthetic random-noise image WebP produced a larger file than JPEG. Content decides the margin, and occasionally the direction.

The measured difference on a photograph

The same 1280 × 854 photograph, encoded at matching nominal quality settings by each format.

WebP recorded higher PSNR than JPEG at every quality level in the table while producing a smaller file at most of them. That is the useful summary: at the settings people actually ship, WebP delivers more fidelity per byte.

Note the crossover at the top. At quality 95 and 90, MozJPEG produced smaller files than WebP. WebP's advantage widens as quality falls and closes as quality rises, because its intra-frame prediction pays off most when many bits are being discarded.

Quality numbers are not comparable between formats

The two encoders map their 0 to 100 scales onto entirely different internal machinery. JPEG quality scales a quantisation table. WebP quality controls a different trade-off across prediction, transform and entropy coding.

The consequence is visible in the table. At quality 80, JPEG produced 67.5 KB and WebP produced 27.0 KB — yet WebP measured 0.37 dB higher in fidelity. WebP at quality 80 is not "the same setting" as JPEG at quality 80. It is a different, more efficient point on a different curve.

When converting a library, do not copy the quality number across. Set a target size, or compare the two outputs visually at display size, and choose from the result.

Where WebP wins by a wide margin

Flat colour with hard edges is where the gap becomes large. Interface screenshots, charts, diagrams, logos with a photographic background, and anything containing rendered text fall in this category.

On the flat graphic WebP produced a file 73% smaller than JPEG and 71% smaller than PNG, while avoiding the coloured fringing JPEG introduces around hard edges. For screenshots and diagrams, WebP replaces both older formats rather than competing with one of them.

Where WebP loses

On a synthetic random-noise image, WebP produced 725.5 KB against 680.7 KB from JPEG at quality 80 — 7% larger. Noise defeats prediction: every block is unrelated to its neighbours, so WebP's prediction step adds overhead without finding anything to predict, while JPEG's simpler pipeline carries less baggage.

Pure noise does not appear in real photography, but heavy film grain, high-ISO sensor noise and densely detailed textures move in that direction. If a grainy photograph converts to a larger WebP than JPEG, this is the reason, and keeping the JPEG is the correct response.

WebP also carries a hard limit that JPEG does not: 16383 pixels in either dimension. Very large panoramas and long stitched screenshots exceed it.

Transparency and animation

WebP supports an 8-bit alpha channel with lossy colour. That combination has no JPEG equivalent and no efficient PNG equivalent: a photograph with a transparent background must be PNG-24 without WebP, which is typically several times larger.

WebP also supports animation, and replaces animated GIF at a large saving. GIF is limited to 256 colours and stores frames inefficiently; animated WebP carries full colour with modern inter-frame compression.

Browser support

WebP is supported by every current browser: Chrome, Edge, Firefox, Safari and Opera, on desktop and mobile. Safari added support in version 14, released in September 2020. Chrome and Firefox have supported it for considerably longer.

The remaining gaps are outside browsers. Some email clients do not render WebP, so keep JPEG or PNG for HTML email. Some older desktop software and image libraries do not open it. A file downloaded by a user may therefore be less portable than a JPEG, which matters when the download is the point.

The fallback pattern

The <picture> element handles both formats without server-side detection. The browser takes the first source whose type it supports.

<picture>
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" width="1280" height="854" alt="Description">
</picture>

Keep the <img> element as the final child. It carries the alt text, the dimensions and the fallback source, and it is what the browser actually renders. Both files must have identical dimensions, or the layout shifts when the fallback is used.

When to stay on JPEG

Files people will download and keep

JPEG opens everywhere, in software going back decades. A downloaded WebP may not.

Images in HTML email

Client support is inconsistent. JPEG and PNG are safe.

Uploads to a form with a stated format list

Many application portals accept only JPEG and PNG, and reject WebP outright.

Photographs with heavy grain

Measure both. The WebP advantage narrows and occasionally reverses.

Anything going to print

Send the original, uncompressed. Neither format belongs in a print workflow.

Where AVIF fits

AVIF compresses better than WebP, particularly at low bitrates, and supports wide colour and high dynamic range. Browser support is now broad but slightly behind WebP, and encoding is markedly slower.

The practical arrangement is a three-way <picture> element: AVIF first, WebP second, JPEG as the <img> fallback. Each browser takes the best format it understands. The cost is three files and three encodes per image, which is worth paying for a hero image and rarely worth it for a thumbnail.

Decision table

Converting an existing library without degrading it

Converting a folder of JPEGs to WebP re-encodes data that has already been through one lossy pass. The artefacts the JPEG encoder introduced are now part of the image, and the WebP encoder faithfully preserves them while adding its own.

The damage is smaller than it sounds, because the second encoder is working on an image whose high-frequency detail was already removed, and there is less left to destroy. It is not zero. Two rules keep it manageable.

Convert from the original wherever the original still exists. A camera file, a raw export or a PNG master produces a materially better WebP than a quality 75 JPEG does.

Where only the JPEG exists, encode the WebP at a slightly higher quality than you would from an original — 82 to 85 rather than 80. The extra bytes preserve the existing artefacts rather than compounding them, and the file is still far smaller than the JPEG it replaces.

Never convert back and forth. JPEG to WebP to JPEG applies three lossy encodes and produces a visibly worse file than either single conversion.

Serving both formats from a server

The <picture> element is the most predictable method, because the decision happens in the browser and nothing is cached incorrectly.

The alternative is content negotiation: the browser sends an Accept header listing the formats it supports, and the server returns WebP or JPEG from the same URL. This keeps markup simple and works for images referenced from CSS, which <picture> cannot help with.

Content negotiation has one requirement that is easy to miss. The response must carry Vary: Accept, or a shared cache will store the WebP it served to one visitor and hand it to a browser that cannot display it. That failure mode is intermittent and depends on cache state, which makes it unpleasant to diagnose. If you serve different bytes from one URL, declare it.

WebP also has a lossless mode

WebP is two formats sharing one container. The lossy mode described above competes with JPEG. A separate lossless mode competes with PNG, and it usually wins.

Lossless WebP reproduces every pixel exactly, like PNG, but uses better prediction and entropy coding. On flat artwork the saving over PNG is typically substantial. It also supports full alpha, so it replaces PNG-24 without the size penalty.

Choosing between the two modes follows the same logic as choosing between PNG and JPEG. Use lossless WebP where exactness matters — logos, artwork that will be edited again, screenshots where you want no artefacts at all. Use lossy WebP for photographs and for screenshots where a small, invisible approximation is acceptable in exchange for a much smaller file.

Most tools expose this as a checkbox rather than a format choice, which is why many people never notice the mode exists and assume WebP is inherently lossy.

Decode time, not just file size

A smaller file is not automatically faster to display. The browser must also decode it, and decode happens on the main thread unless the image is handed to a decoder that can run elsewhere.

WebP decodes somewhat more slowly than JPEG per pixel, because its prediction step does more work. On a modern phone the difference is small enough to be dominated by the saving in transfer time, which is why WebP still wins on almost any real connection. On a very fast local network with very large images, the arithmetic can invert.

The practical consequence is about dimensions rather than format. A 4000-pixel image costs decode time proportional to its pixel count no matter how small the file is. Resizing reduces both transfer and decode; changing format reduces only transfer. That is another reason resizing comes first.

Measure your own images before committing

The figures in this article describe one photograph and three synthetic images. Your library will differ, sometimes substantially, and the test takes minutes.

Take a representative sample — a dozen images spanning the kinds of content you actually publish. Encode each as JPEG at quality 80 and WebP at quality 80. Compare total bytes, then look at three or four of them side by side at the size they are displayed on your site.

Two outcomes are worth watching for. If the WebP total is not meaningfully smaller, your images are probably already heavily compressed, and the win is not there. If individual WebP files are larger than their JPEG counterparts, that content is noisy — grain, texture, foliage — and those specific images should stay as JPEG.

How these numbers were measured

Source: one photograph, 1280 × 854 pixels, plus three synthetic images at identical dimensions marking the extremes of compressibility. All were held as lossless PNG and decoded once into raw RGB as the reference.

Encoders: libvips 8.17.3 through sharp 0.34.5 — libjpeg-turbo and MozJPEG for JPEG, libwebp 1.6.0 for WebP. PSNR was computed across all three colour channels. Sizes are exact byte lengths converted at 1024 bytes per kilobyte.

Limits. One photograph is not a benchmark suite. PSNR rewards arithmetic closeness rather than perceived quality, and WebP's smoothing behaviour tends to score slightly better on PSNR than a viewer would judge it — so read the fidelity columns as approximate parity rather than a WebP win. The synthetic images mark boundaries; they are not typical content. Browser support statements reflect shipping versions as of 2026.