Tooooolbox
100% private
June 29, 2026 · 7 min read
If you've looked into speeding up a website, you've almost certainly been told to "use WebP." It's one of the most recommended image optimisations of the last decade — but what actually is WebP, how much does it really save, and is it the right choice for you? Here's a plain-English answer.
WebP is an image format developed by Google, designed specifically for the web. Its goal is simple: deliver the same visual quality as JPEG and PNG in a noticeably smaller file. It does this with more modern compression than either of those older formats, and it can do the jobs of both — photographs and graphics — in a single format.
Unlike JPEG, which is lossy only, and PNG, which is lossless only, WebP offers both modes. That flexibility is a big part of why it caught on.
In lossy mode, WebP is typically 25–35% smaller than a JPEG at the same visual quality. In lossless mode, it's usually around 20–30% smaller than an equivalent PNG. On a page full of images, that easily translates into hundreds of kilobytes — often megabytes — of savings, which means faster loading, lower bandwidth costs and better search rankings.
Those numbers vary with the image: photos with lots of fine detail save less, flat graphics save more. But in almost every case, WebP wins on size.
WebP supports transparency (an alpha channel), just like PNG — so you can use it for logos, icons and overlays with transparent backgrounds while keeping the file lighter. It also supports animation, making it a lighter modern alternative to animated GIFs.
In other words, WebP can replace JPEG, PNG and GIF all at once, which simplifies how you handle images on a site.
This used to be the main objection to WebP, but it's no longer a real concern: every major browser — Chrome, Firefox, Safari, Edge — has supported WebP for years. In practice, well over 95% of users can view WebP images without any issue.
The main exceptions are very old software and some desktop applications or email clients that expect a classic format. So for the open web, WebP is safe; for a file you're emailing to someone or uploading to an unknown system, a JPEG or PNG is still the safer bet.
This is the part most introductions skip, and it explains a lot of confusion. WebP has two entirely separate compression modes, and they behave nothing alike. Lossy WebP discards information the way JPEG does, and is what you want for photographs. Lossless WebP keeps every pixel exactly, the way PNG does, and is what you want for logos, icons and screenshots.
The practical difference is large. Lossless WebP typically comes out around 25% smaller than an equivalent PNG — a modest but completely free saving, since nothing is lost. Lossy WebP compresses far harder, routinely 25–35% smaller than a JPEG of matching visual quality, and 60–80% smaller than the same image stored as PNG.
Most tools pick a mode for you based on the source format, which is usually right but occasionally not. If you are converting a photograph that someone mistakenly saved as PNG, forcing lossy mode is what turns a 4MB file into a few hundred kilobytes.
WebP's lossy mode comes from VP8, a video codec, and it inherits the single most important idea in video compression: prediction. Before encoding a block of pixels, the encoder looks at the neighbouring blocks it has already decoded and predicts what this one probably looks like. It then stores only the difference between the prediction and reality.
Because adjacent areas of a photograph usually resemble each other, that difference is far smaller than the block itself, and small numbers compress well. JPEG, designed in 1992, has no equivalent step — it encodes every 8×8 block independently, with no knowledge of what surrounds it.
The lossless mode uses a different set of tricks entirely: it looks for exact pixel patterns that have already appeared, builds local colour palettes, and applies transforms that make repeated structures cheaper to store. That is why it does so well on graphics and so poorly on photographs, exactly like PNG.
AVIF compresses harder. On photographic content it typically produces files 20–30% smaller than WebP at matching quality, and around 50% smaller than JPEG. It also supports HDR, wide colour gamuts and 10- or 12-bit colour depth, which eliminates the faint banding that both JPEG and WebP can show in a smooth twilight sky.
WebP wins on everything else. It encodes several times faster, which matters when you are processing a batch or converting in the browser. It is supported by more non-browser software. And its decoding is lighter, which is a real consideration on low-end phones.
The pragmatic answer for a website is to use both: serve AVIF to browsers that accept it, with WebP as the fallback, and let the browser choose. If you are picking a single format for general use — sharing files, storing an archive, uploading somewhere — WebP is still the safer choice, because the odd application that rejects AVIF is more common than one that rejects WebP.
It is worth being clear about the weaknesses, because most WebP write-ups read like advertising. The biggest practical problem is software outside the browser: older versions of Photoshop, plenty of print shops and photo labs, some marketplace and e-commerce upload forms, older Office builds and various digital photo frames still refuse WebP files outright.
WebP also has no progressive rendering. A large JPEG can appear immediately as a blurry preview and sharpen as more data arrives; a WebP appears only once enough of it has downloaded. On a slow connection that changes how loading feels, even when the WebP is the smaller file.
Finally, lossy WebP tops out at 8-bit colour depth and uses 4:2:0 chroma subsampling, meaning colour is stored at half resolution. For most photographs this is invisible. For images with saturated red text on a dark background — a surprisingly common case in graphics — it can produce visible colour fringing that lossless mode or PNG would not.
For one-off conversions, a browser-based converter is the simplest route and keeps the file on your own machine. Drop the image in, choose a quality level, and download the result. For photographs, 75–85% quality is the range where the saving is large and the loss is not visible; below about 70% you start to see softness in fine detail.
One rule matters more than the settings: convert from the highest-quality original you have. Converting a JPEG to lossy WebP applies a second round of destructive compression to an image that has already lost information, and the artefacts compound. If the original camera file still exists, encode from that instead.
If you run a website, the conversion is usually better handled automatically. Most modern frameworks and CDNs will generate WebP and AVIF variants on the fly and serve whichever the visitor's browser accepts, which avoids maintaining three copies of every image by hand.
For images on your own website: yes, almost always. The size savings are real and the compatibility is there. If you want a safety net for ancient browsers, serve WebP with a JPEG or PNG fallback — most website platforms and CMSs can do this automatically.
For images you send to people or upload elsewhere: stick with JPEG for photos and PNG for graphics, since you can't control what software will open them. Converting is easy either way: drop your image into our compressor, choose WebP as the output format, and download the lighter version — it all happens in your browser, so nothing is uploaded.