[Sammi]

You can really treat WebP as a universally available format in 2026. It is an old, boring, and safe format to use now.

Browser support for WebP is excellent now. The last browser to add it was Safari 14 in September 16, 2020: https://caniuse.com/webp

It got into Windows 10 1809 in October 2018. Into MacOS Big Sur in November 2020.

Wikipedia has a great list of popular software that supports it: https://en.wikipedia.org/wiki/WebP#Graphics_software

[carra]

Unfortunately being universal implies way more than just having good browser support. There are quite a few image processing programs without webp or jpeg-xl support. I'm using Windows 11 and the default image viewer can't even open webp... Also, keep in mind that due to subscription models there are many people stuck with older Photoshop versions too.

[spider-mario]

You just need this: https://apps.microsoft.com/detail/9pg2dk419drg

[carra]

Thanks, I know about this and other workarounds. My point is, if it was truly universal you should not need anything! I bet most regular users will never even know this exists.

[majora2007]

I never knew about this either and it's been very frustrating as I've been converting my Manga library over to webp (savings are insane) and doing any spot checking opens Edge.

Edit: After reading the comments, this doesn't seem to open in Photos App.

[Y-bar]

Webp can be really annoying once you hit certain encoding edge cases.

One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.

[jdiff]

Just out of curiosity, what's the problem libwebp has with them? I wasn't aware of cases where any image format would just cross its arms and refuse point blank like that.

[Y-bar]

We have never been able to resolve it better than knowing this:

Certain pixel colour combinations in the source image appear to trip the algorithm to such a degree that the encoder will only produce a black image.

We know this because we have been able to encode the images by (in pure frustration) manually brute forcing moving a black square across the source image on different locations and then trying to encode again. Suddenly it will work.

Images are pretty much always exported from Adobe, often smaller than 3000x3000 pixels. Images from the same camera, same size, same photo session, same export batch will work and then suddenly one out of a few hundred may become black, and only the webp one not other formats, the rest of the photos will work for all formats.

A more mathematically inclined colleague tried to have a look at the implementation once, but was unable to figure it out because they could apparently not find a good written spec on how the encoder is supposed to work.

[jfoster]

Can you try converting one of them here? I'm curious whether it works or not.

https://bulkresizephotos.com/en?preset=true&scale=100&format...

If it doesn't work, any chance I could have a copy of one of the images for testing with? (and trying to file the right bugs to get it fixed)

[SahAssar]

Have you reported this bug? It sounds interesting what the authors would say.

[Y-bar]

No. Our experience with reporting issues in Skia and other such Google libraries has left a bitter impression, so we simply avoid it.

[tr45872267]

Webp has a maximum pixel dimension size of 16383 x 16383.[0]

[0] https://developers.google.com/speed/webp/faq#what_is_the_max...