Resize WebP

Serving properly sized WebP images minimizes Largest Contentful Paint (LCP) delays by eliminating excessive layout decoding times.

No, and the naming causes real confusion. Lossless describes the encoder: it stores the pixels it is given exactly, with no compression artifacts. The resize happens before that, and changing an image's dimensions always means computing new pixels from old ones, which discards information by definition. So Lossless WebP guarantees the output matches the resized image perfectly — not that it matches the original you uploaded.

A practical set is 640, 1024, 1600 and 2560 pixels wide, generated from the largest original you have rather than from each other. That covers phones, tablets, ordinary laptops and high-density desktop displays without producing a dozen near-identical files. The point of srcset is that the browser downloads only the one it needs, so the win comes from having a genuinely small option available, not from having many options.

Browsers cap how large a canvas can be, both in total area and in any single side, and the cap is undocumented and differs by browser and device — iOS Safari is far stricter than desktop Chrome. Past that ceiling nothing throws an error: the canvas simply stays blank and still encodes to a technically valid, completely empty image. PDFixel clamps requested dimensions below the safe ceiling and tells you when it has done so, rather than handing back an empty file that looks like a successful export.

For displaying images, yes — every current browser decodes WebP. The gap is on the production side and in older desktop software: canvas WebP encoding is missing in older Safari, and some long-lived design and office applications still will not open a .webp file. This tool probes the browser with a one-pixel test encode before committing to the format, so if WebP genuinely cannot be produced you get a correctly named fallback instead of a file with the wrong extension.