WebP: What the Format Is and When It Beats JPG

A product page crawls on mobile data even though there is barely any text on it. Twenty photos at 300 KB each add up to 6 megabytes, and almost all of that page weight comes from the images. The designer sends over files that were already "optimized for the web" and they still weigh two megabytes apiece, because they were saved as JPG at quality 100. That is when the question about formats comes up: WebP promises the same picture in a smaller file. Here is what the format actually is, where it came from, when it really does beat JPG, and when the sensible move is to leave the files alone.

What WebP is and where it came from

WebP is a raster image format developed by Google and released on 30 September 2010. The ambition was broad from the start: replace three web formats at once, JPEG for photographs, PNG for graphics with transparency, and GIF for animation. At its core sits the VP8 codec, the very same one used in WebM video, so anyone who has met a video codec on the web will find much of it familiar. A WebP file is wrapped in a RIFF container: the first four bytes read as "RIFF", bytes eight through eleven hold the identifier "WEBP", and the data block follows. That block may contain VP8 for lossy compression, VP8L for lossless compression, or the extended VP8X block when the file carries animation and an alpha channel. Additional chunks can hold an ICC colour profile, EXIF data and XMP metadata alongside the picture.

• developed by Google, first release on 30 September 2010;
• lossy compression is built on the VP8 codec, the lossless variant is called VP8L;
• the lossless mode was announced on 18 November 2011 and enabled by default in libwebp 0.2.0 from 16 August 2012;
• animation arrived in the extended format on 3 October 2011;
• the file lives inside a RIFF container and can additionally carry an ICC profile, EXIF and XMP;

Two compression modes: lossy and lossless

Lossy compression works exactly like JPEG: information is dropped on purpose, the eye does not notice, and the file ends up noticeably smaller. That is the mode used for photographs. Lossless compression squeezes the image without losing a single pixel, so what comes out matches the source down to the finest detail. PNG is the familiar comparison here, because PNG is lossless too, but WebP does a better job of it, and Google claims a file 26 percent smaller than the equivalent PNG.

• photographs: lossy, because size matters more than pixel accuracy and the difference is invisible on screen;
• logos, icons, diagrams with text: lossless, since every edge has to stay sharp, and PNG files for that job are usually transparent as well;
• animation: WebP in the extended format, which is far lighter than GIF at the same frame count;
• interface screenshots: a genuinely mixed case, since small text compresses better without losses, but a photographically rich screenshot tends to favour WebP;

A 4 MB JPG photograph compresses to roughly 30 percent less in WebP, per Google:
   4 MB × 0.7 = 2.8 MB

A transparent 1.2 MB PNG in the lossless variant:
   1.2 MB × 0.74 = 0.89 MB   (26 percent less, per Google)

A gallery of 20 photographs:
   JPG:  20 × 4 MB = 80 MB
   WebP: 20 × 2.8 MB = 56 MB
   difference: 24 MB on a single page

What WebP actually buys you

The main argument is weight. According to Google, WebP compresses about 30 percent better than JPEG on average with no visible loss of quality, while the lossless variant comes out roughly 26 percent smaller than PNG. The numbers for animation are better still: converted from GIF, lossy WebP animation is reported to be 64 percent smaller and the lossless version 19 percent smaller. The second effect is speed. A smaller file means less traffic and a faster page, and both feed straight into Core Web Vitals and into how visitors behave: a page that takes longer than three seconds on mobile data loses about half its audience.

• Chrome on the desktop has supported WebP since version 17, lossless and transparency since 23, and animation since 32;
• Firefox supports it from version 65, Edge from 18, and Opera from 19 for animation;
• Safari joined in version 14, that is from September 2020, and until then it was the last major browser without support;
• on Windows the Photos app opens WebP files, while File Explorer needs the separate WebP Image Extensions package from the Microsoft Store;

JPEG, PNG, WebP and AVIF: picking one

• JPEG: lossy, no transparency, no animation, supported everywhere, and not something you can recompress without losing more quality;
• PNG: lossless, transparency yes, animation no, the right choice for screenshots, logos and diagrams, and pointlessly large for photographs;
• WebP: both lossy and lossless, transparency and animation in a single format, supported by every current browser;
• AVIF: lossy compression built on the AV1 video codec, transparency and animation included, better quality at the same size, but support is still uneven: Chrome from 85, Firefox from 93, Edge from 121, Safari partially from 16.1 and fully from 16.4;

WebP or AVIF: what to pick today

The rule of thumb is simple. If broad compatibility matters most right now, WebP is the safer bet, since every current browser has handled it since 2020. AVIF produces a smaller file, but full Safari support only arrived in version 16.4 and some Android devices still lag behind. The scheme that tends to win is to serve AVIF first, WebP second and JPG last, which means older browsers still get a picture either way.

Do Yandex and Google need WebP?

For Google the answer is documented directly: the list of formats the search engine can index alongside images names BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. A WebP picture is therefore indexed and can appear in image search on equal terms with a JPG. Yandex is less clearly defined: there is no official list of supported formats, and forum discussions regularly mention WebP images failing to show up in image results. The practical conclusion is that if images bring in traffic, keep the JPG and serve both formats, which is the next topic.

• for indexing in Google the WebP format is fine, with no extra conditions;
• in Yandex, relying on WebP alone is risky, especially where images account for a visible share of traffic;
• the alt attribute and the file name work the same way for every format and make no difference to indexing;
• for Google Images it matters more that the image is reachable at a plain URL and available to the crawler without JavaScript;

Serving WebP and JPG together: picture and type

The right approach is not to pick a format by hand but to hand the browser both options and let it decide. That is what the picture element is for: source elements carrying a type attribute come first, and a plain img follows as the fallback. The browser walks the list from the top and takes the first source whose type it understands. If WebP is unsupported, that source is skipped and the img is used instead. When support exists, the img is ignored entirely, so exactly one file crosses the network.

<picture>
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Product name" width="1200" height="630">
</picture>

What happens in the browser:
Chrome, Firefox, Edge, Safari 14+  → first source, the .webp file
older Safari, Internet Explorer      → img, the .jpg file
a crawler that ignores picture       → img, the .jpg file

The type attribute is required. Without it the
browser downloads the .webp and shows a broken image.

For retina screens add srcset with two widths,
otherwise the picture looks blurry:

<source srcset="/img/hero-800.webp 800w,
                /img/hero-1600.webp 1600w"
        type="image/webp" sizes="(max-width: 600px) 100vw, 600px">

Typical mistakes when moving a site to WebP

• the files were converted but HTML and CSS still point at .jpg, so the browser keeps downloading the heavy original and some CDN paths still serve the old addresses: check that every path was switched, including the theme and inline styles;
• EXIF was lost: re-encoding through a canvas does not carry EXIF across, so the orientation stored in the file and the GPS coordinates disappear, which means the rotation has to be applied beforehand;
• the photo was compressed several times in a row, so every pass inherits the flaws of the one before it, the quality drops and the file stays heavy anyway;
• quality was set to 100 and the size came as a surprise: the quality parameter behaves as it does in JPEG, and values from 90 down to 82 usually give the best balance for photographs;
• transparency was lost when converting to JPG: JPEG has no alpha channel, transparent areas get filled with the background colour, and a visible rectangle appears on white;
• the dimensions were forgotten: without width and height the browser cannot reserve space, the layout jumps on load, and that hurts both speed and behavioural metrics;

How to compress a photo properly before publishing

1. start from the original rather than a compressed JPG from a chat app, because every intermediate compression costs quality;
2. resize to what the page actually needs: a gallery rarely needs more than 1200 to 1600 pixels wide, not four thousand;
3. pick the mode by content: photographs go lossy, logos and diagrams go lossless;
4. tune the quality: for photographs start at 82 and compare the result against the original side by side rather than by eye alone;
5. check the transparency if there was any, because it does not survive the trip to JPG;
6. keep a JPG version alongside for whatever still needs it, and serve both through picture.

All of this can be done in the browser with nothing installed. The WebP to JPG converter reads a file, works out its real format from the first bytes, and hands back JPG, PNG or WebP at a quality you choose, filling transparent areas with a picked colour when saving to JPG so the result can go straight into the layout. Dimensions are easier to set with the image resizer, proportions for cropping go through the aspect ratio guide and the image cropper, and when a picture has to be embedded straight into markup or CSS, the image to Base64 tool takes care of it.

Common questions

What makes WebP better than JPG?

Weight comes first: by Google own figures the same frame takes roughly 30 percent less space in WebP than in JPEG while looking indistinguishable. Convenience follows, because one format covers transparency, animation and lossless compression, so JPG, PNG and GIF can all be replaced by a single file. There is a flip side, and it is worth remembering: a JPG cannot be recompressed into a JPG without further loss, whereas turning a JPG into WebP is perfectly fine and is the normal path for a website.

Why does Windows refuse to open WebP?

The operating system understands the format, but File Explorer shows a placeholder icon for it by default. The Photos app in Windows opens WebP without trouble, and to get proper previews inside File Explorer you install the free WebP Image Extensions package from the Microsoft Store, which was released for Windows 10 and 11. A browser on the same machine needs none of that, since it handles the format out of the box.

WebP or AVIF?

If compatibility comes first, choose WebP, since every current browser has supported it since 2020. If the smallest possible file matters more and you are prepared to handle conditional support, look at AVIF, but then a scheme with three formats is the way to go. The compromise that most often wins is to serve AVIF first, WebP second and JPG last, rather than trying to get by with a single format.

Do photos need converting for a website?

Usually yes, when the files arrive straight from a camera or from an editor set to quality 100, because such shots weigh several times more than anything a screen can show. If the pictures have already been compressed for the web once and sit next to finished markup, converting them pays off mainly where dozens of images are involved. For a single hero image, a few hundred kilobytes usually make no difference at all.

Can I make WebP out of PNG?

Yes, and for graphics with transparency it is usually the best route: the lossless variant lands roughly 26 percent smaller than PNG while keeping the alpha channel and crisp edges. Converting to JPG instead is a mistake, because JPG simply cannot carry transparency. One thing to keep in mind is that the PNG you convert is the starting point, not the pre-compression original, so a heavily squeezed PNG will not turn into a better picture through a lossless WebP.

How do I compress without visible loss?

Compare the result at full size and at matching brightness rather than in a thumbnail, because most WebP artefacts show up in thin gradients that a small preview hides. A workable order is to start at quality 82, raise it to 88 if the picture looks soft, and stop at the point where further increases produce no visible difference. The file size keeps moving as quality changes, while the visible result stops.