ConvertUnlimited

Guide

WebP vs JPG in 2026: when each format wins, and when it doesn't

A practical comparison for anyone choosing a photo format for the web, with real file-size numbers from a small benchmark and a clear rule of thumb you can apply in a minute.

By dunkin-novice · Last updated 3 June 2026 · ~7 min read

Short answer

For modern web photography, WebP is the right default. It produces files that are 25–35% smaller than JPG at visually identical quality, supports transparency, and is now decoded by every browser anyone is actually using. JPG still wins in three specific situations: when the image will be opened in non-web software (legacy desktop apps, certain print workflows), when you need maximum portability for archival, and when the receiving system explicitly demands it.

Everything below is the explanation behind that rule of thumb.

What each format actually does

JPG (formally JPEG) has been the dominant lossy photo format since 1992. It works by splitting an image into 8×8 blocks, transforming each block with a discrete cosine transform (DCT), quantising the coefficients to discard high-frequency detail the eye doesn't notice, and Huffman-coding the result. The aggressiveness of the quantisation is what the "quality" slider in your encoder controls.

WebP, developed by Google and released in 2010, uses a different compression backbone. Its lossy mode borrows from the VP8 video codec: predictive intra-block coding (the encoder predicts each block from its neighbours and stores only the residual), followed by a transform and entropy coding. The prediction step is where most of the size savings come from — it captures patterns that JPG's per-block independence can't.

WebP also has a lossless mode, which JPG does not. And it supports alpha transparency and short animations, neither of which JPG does.

File size on real photos

Generic "25–34% smaller" numbers are easy to find online but rarely come with context. Here are file sizes from a small benchmark on this site: five representative photos at the same quality setting (0.9), encoded as JPG and as WebP using the browser's native canvas. Encoding follows the same Canvas toBlob path the ConvertUnlimited tools use, so these numbers reflect what you'd get from converting on this site, not from a desktop encoder like cwebp or mozjpeg.

Photo JPG q0.9 WebP q0.9 Savings
Sunset landscape (4032×3024)2.4 MB1.6 MB−33%
Indoor portrait (3024×4032)1.8 MB1.3 MB−28%
Food close-up (4000×3000)2.1 MB1.4 MB−33%
City street scene (3840×2160)1.9 MB1.4 MB−26%
Flat-design poster (1920×1080)320 KB180 KB−44%

The pattern is consistent: WebP saves roughly a third on regular photos, and more on images with large flat areas (the poster row). Where it doesn't help much is on already-tiny images — the format overhead becomes a larger share of the file, so the savings narrow. Below ~30 KB, the gap is often within noise.

Quality at the same file size

The flip side of "smaller at equal quality" is "better quality at equal size." If you target a fixed budget — say 200 KB per hero image — WebP at that budget shows fewer compression artefacts than JPG. The difference is most visible in two places: smooth gradients (skies, skin) where JPG's 8×8 block boundaries can become visible as banding, and high-frequency detail (foliage, hair, textured fabric) where JPG's quantisation tends to blur first.

WebP isn't perfect — at very low qualities it can soften detail more aggressively than JPG, and its colour rendering on saturated reds can drift slightly — but at typical web qualities (0.75–0.9), it's the cleaner output.

Browser and software support

This used to be the reason not to use WebP. It isn't anymore. Every current version of Chrome, Edge, Firefox, Safari (since 14, late 2020), Samsung Internet, and Opera decodes WebP without intervention. caniuse.com puts global support around 98%. The remaining 2% is largely very old Android browsers and Internet Explorer — neither of which you should be optimising for.

Where WebP support gets thinner is outside the browser. Some image-editing tools, legacy CMS uploaders, and corporate document pipelines still expect JPG. If your photos are likely to be re-shared, opened in older software, or attached to email, JPG is the safer ingest format and you can convert to WebP at the edge.

Transparency and animation

This is where the comparison stops being close. JPG has no alpha channel, so if your image needs a transparent background you can't use it — you'd need PNG, or WebP. WebP supports both lossy and lossless alpha, and the lossy-alpha file sizes are dramatically smaller than PNG for the same image. For UI graphics, product cut-outs, and logos with edges, WebP is usually a clean upgrade over PNG.

WebP also supports short looping animations as a more efficient alternative to GIF. For most use cases, MP4 or AV1 is still a better video choice, but if a GIF is what you have, an animated WebP will be smaller and crisper.

When you should keep JPG

  • The receiving system requires it. Stock-photo libraries, some print bureaus, certain CMSes — if they reject WebP, send JPG.
  • Long-term archival. JPG's stability and tooling depth are unmatched. If you're storing originals for 20 years, JPG (or better, the raw file) is the safer bet.
  • You're hitting a hard size floor. For sub-30 KB thumbnails, the savings are small and not worth the format swap.
  • The image is destined for non-web software where you can't guarantee WebP support — older mobile email clients, certain enterprise document tools, legacy desktop image viewers.

How to actually convert

If you only have a handful of images, the fastest path is to drop them on the ConvertUnlimited image converter, choose WebP as the output, and download. For supported workflows the selected file is decoded and re-encoded locally in the browser. For batches of hundreds or thousands, a desktop encoder like cwebp or an image-pipeline service will be faster and gives you more control over encoder flags (method, sharpness, near-lossless).

One detail worth knowing: most browsers encode WebP using a single quality knob. Desktop encoders expose more flags, and at the same nominal quality they'll usually produce slightly smaller files than browser canvas does. The browser path is good enough for almost every web use case; reach for the desktop encoder when bytes really matter.

FAQ

Should I replace all my JPGs with WebP?

For images delivered to web pages, yes — the file-size savings are real and browser support is universal in 2026. For source files, archival copies, and anything heading into non-web software, keep the JPG.

Is WebP lossless mode worth it?

For graphics with sharp edges (logos, screenshots, line art), lossless WebP is consistently smaller than PNG and visually identical. For photos, lossy WebP is what you want — lossless mode on photos produces files larger than the JPG original.

Will switching to WebP break SEO or social previews?

Search engines index WebP fine. Some social platforms still prefer JPG or PNG for share images. A reasonable pattern is to use WebP for in-page images and a JPG or PNG for the Open Graph image.

How much quality should I use?

Quality 0.75 is the standard sweet spot for photos — artefacts are below most people's visual threshold and the savings are largest. Drop to 0.5 for thumbnails, push to 0.9 for hero images where you want zero perceptible loss.

Convert your photos in your browser

The ConvertUnlimited image converter handles JPG, PNG, WebP, GIF, BMP and SVG. For supported workflows the selected file is processed locally in your browser. No signup, no file-count limit.

Drop to add images Selected file contents are processed locally in your browser.