Why Google made a new image format
By 2010, images were the bulk of what a web page downloaded, and the formats doing the work were from 1992 and 1996. WebP was Google’s attempt to replace both at once.
It borrows its compression from VP8, a video codec, applying the prediction techniques video coding had developed to still images. The same idea appeared later, more aggressively, in AVIF.
Crucially it also merged two roles. Before WebP you chose between JPG’s compression and PNG’s transparency. WebP does both, including the previously impossible combination of lossy compression with an alpha channel.
What the saving actually is
Measured on the fixed test image used throughout this site, from the same source:
Your own images will differ. Photographs with heavy fine texture narrow the gap; images with large areas of flat colour widen it.
The compatibility asymmetry
This is the thing to understand about WebP, and it explains almost every problem people have with it.
In browsers, WebP is universal. Chrome, Edge, Firefox, Opera and Safari all render it, and have since Safari joined in 2020.
Outside browsers, it is patchy. Many desktop photo viewers, plenty of older editors, most print workflows and a long tail of upload forms still reject it.
So a format designed to be served by websites is served by websites — and the moment you save one of those images to your disk, you are outside the environment it was designed for. That mismatch is why “how do I open a WebP file” is such a common question.
Practical rules
- Publishing to a site you control — use WebP. The bandwidth saving is real and every visitor’s browser can read it.
- Sending a file to a person — convert to JPG. You cannot predict their software.
- Editing — convert to PNG if your editor refuses WebP, accepting that it will be much larger.
- Squeezing further — convert to AVIF, if your audience is current.
Converting into WebP
If you are converting iPhone photos for a website, go directly from HEIC rather than via JPG — two lossy steps discard more than one.