Even though AVIF decoding support is fairly widespread by now, it is still not ubiquitous like JPEG/PNG/GIF. So typically services will store or generate the same image in multiple formats including AVIF for bandwidth optimization and JPEG for universal client support. Browser headers help to determine compatibility, but it's still fairly complicated to implement, and users also end up having to deal with different platforms supporting different formats when they are served WebP or AVIF and want to reupload an image somewhere else that does not like those formats. As far as I can tell, JXL solves that issue for most websites since it is backwards-compatible and can be decoded into JPEG when a client does not support JXL. I would happily give up a few percent in compression efficiency to get back to a single all-purpose lossy image format.
Even Google photo does not support avif.
It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.
> Even Google photo does not support avif
I have no previous first-hand knowledge of this, but I vaguely remember discussions of avif in google photos from reddit a while back so FWIW I just tried uploading some avif photos and it handled them just fine.
Listed as avif in file info, downloads as the original file, though inspecting the network in the web frontend, it serves versions of it as jpg and webp, so there's obviously still transcoding going on.
I'm not sure when they added support, the consumer documentation seem to be more landing site than docs unless I'm completely missing the right page, but the API docs list avif support[1], and according to the way back machine, "AVIF" was added to that page some time between August and November 2023.
[1] https://developers.google.com/photos/library/guides/upload-m...
Some years ago, the Google Photos team asked the Chrome team to support JXL, so that they could use it for Photos. The request was ignored, of course.