What is WebP?

What it is

WebP is an image file format published by Google in 2010. It is not a new kind of picture - a WebP holds the same grid of pixels a JPEG or a PNG would - it is a more efficient way of writing those pixels down. Its compression comes from the VP8 video codec: the technique for squeezing a single video frame, applied to a still image.

The problem it was built for is that the web had three image formats and each did one job badly outside its lane:

• JPEG compressed photographs well, but could not do transparency at all and softened hard edges and text.
• PNG handled transparency and flat colour perfectly and never lost a pixel, but produced enormous files for photographs.
• GIF was the only one that could animate, and paid for it with a 256-colour limit and poor compression.

Each of those is taken apart properly in Web image formats. A typical page carried all three and inherited each one's weakness. WebP covers all three jobs: lossy compression for photographs, lossless for flat art, transparency in both, and animation. One format, one decision.

Lossy and lossless in one format

Two terms first, because everything else depends on them.

Lossy compression throws away detail the eye is unlikely to miss, and the discarded detail is gone for good - you cannot reconstruct the original from the file. Lossless compression finds a more compact way to write exactly the same pixels, so decoding gives you back the original, pixel for pixel. Lossy files are far smaller; lossless files are faithful.

JPEG is lossy only. PNG is lossless only. WebP does both, and you choose per file. That is the part people miss: "converting to WebP" is not one decision, it is two.

• Photographs and rendered scenes - lossy. There is no visible detail to protect, and the saving is enormous.
• Screenshots, logos, diagrams, anything with text or flat blocks of colour - lossless. Hard edges are exactly what lossy compression smears.

There is a third setting, near-lossless, which allows a small controlled amount of loss to shrink flat images further. It is a fine-tuning knob, not a starting point.

Transparency and animation

WebP supports an alpha channel - per-pixel transparency - in both its lossy and lossless modes. That combination is the one thing neither older format could offer. Before WebP, a photographic image with a transparent background had to be a PNG, which meant lossless, which meant a very large file. WebP lets it be lossy and transparent at the same time, which is often the difference between 800 KB and 80 KB.

It also animates, which makes it a straight replacement for GIF. An animated GIF is limited to 256 colours and compresses badly; the same animation as WebP is full colour and a fraction of the size.

One caveat on that: if you are shipping something longer than a couple of seconds, neither format is the answer. Use a real video file. An animated image has no audio, no playback controls, and no ability to stream - it downloads entirely before it plays.

How much smaller, really

Google's own published figures are that lossy WebP is 25 to 34% smaller than a JPEG of equivalent quality, and lossless WebP about 26% smaller than the same PNG. Those are the vendor's numbers, from the vendor's study, so treat them as a claim rather than a fact.

Here is a measurement instead. The cover image on Learn Python is a 1672 x 941 photographic render. We encoded the identical source four ways:

Read that table carefully, because the headline number is misleading. Most of the 91% is not WebP. It is the switch from lossless to lossy - the JPEG saved 88% doing the same thing. The honest measure of what WebP itself contributed is the comparison against the JPEG: 173 KB against 221 KB, or 22% smaller. That is short of Google's claimed 25 to 34%, which is the ordinary shape of a vendor benchmark: published figures describe the cases that flatter the format, and any single real image lands where it lands.

One caveat on our own number, in fairness to WebP. The JPEG was encoded at quality 85 and the WebP at 88, and those are different encoders with different quality scales - not a matched pair. The WebP was asked for slightly more quality and still came out smaller, so if anything the comparison understates it. Treat 22% as indicative of the order of magnitude, not as a benchmark.

So the useful framing is not "WebP saves 90%". It is: choosing lossy over lossless is the big win, and choosing WebP over JPEG takes roughly another fifth off on top, for free, with no visible difference.

Browser support, and fallbacks

Every current browser decodes WebP, and has for six years.

Safari was the last holdout, and iOS 14 reached every iPhone back to the 6s. In practice that means every phone, tablet, and desktop browser in current use renders these images.

The practical consequence: you no longer need a fallback. The old pattern of wrapping every image in a <picture> element with a JPEG alternative was correct in 2019 and is now dead weight in almost every project. Ship the WebP.

Support is thinner outside the browser, and that is worth knowing before you convert everything you own:

• Email. Client support is patchier than the web. For an HTML email, stay with JPEG or PNG.
• Desktop and print tools. Older image editors, office software, and print workflows may not open a .webp at all.
• Anything you hand to someone else. A file a colleague has to open is not the same problem as a file a browser has to render.

None of that is a reason to avoid WebP on a web page. It is a reason to keep the original file somewhere, which you should be doing regardless - see the next section.

Converting your images

Four tools cover essentially every situation:

• Squoosh - a web app with a side-by-side quality slider. The best place to start, because you can see what each setting costs before committing.
• cwebp - Google's own command-line encoder, from the libwebp package. What you want for a folder of images.
• ImageMagick - if it is already in your pipeline, it converts WebP too.
• Your build tool or CDN - most modern ones will convert and serve WebP automatically, which is the right answer at scale.

The command-line version is one line:

# photographic image: lossy, quality 85
$cwebp -q 85 hero.png -o hero.webp

# screenshot or flat art: lossless, no quality setting
$cwebp -lossless diagram.png -o diagram.webp

On quality settings. For photographs, 80 to 90 is the useful band. Below about 75 the artifacts become findable; above 90 the file grows quickly for a difference nobody sees. Aim for visually lossless rather than as small as possible - the last 40 KB is never worth a visible smudge.

What to check before shipping. Three things fail first, so look at those and ignore the rest: small text, hard edges, and smooth dark gradients. Open the result at 2x magnification and inspect those regions specifically. If any of them look mushy or show banding, raise the quality and re-encode - do not give up and go back to PNG.

Keep the original. Lossy compression is one-way, and each re-encode of an already-lossy file loses a little more. Keeping the untouched source next to the compressed copy means you can re-encode at a different quality, or to a different format, without going back to whatever tool produced it. It costs disk space and it saves you exactly once, which is enough.