If you use the <picture> element [0], then you can specify a MIME type on the srcset. Browsers will then use this to load an image they support - so if you have a set of pictures with a MIME type of image/webp and others with image/jpeg, WebP will be used by those browsers that support it and JPEG by those that don't. There's a good example at [1].

Alas although most browsers support the picture element, IE11 is the notable exception [2] and a polyfill is required.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...

[1] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

[2] https://caniuse.com/#feat=picture

You can use HTML <picture> elements to provide provide multiple image format versions for an <img> element e.g. preferentially use webp if browser supported, and fallback to using a widely supported format if not. Sounds like doing that might be of interest to you.

> I'd like to support it in my own websites, but I literally can't since a huge chunk of visitors use Safari.

Wouldn’t using the <picture> element[0] allow this this? It’s pretty widely supported (every browser that supports WebP and Safari)[1] and allows a fallback to a JPEG in an <img> tag.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...

[1] https://caniuse.com/#feat=picture

Would this be susceptible to tracking issues? E.g. place a hidden picture that loads WebP or PNG otherwise, to track which users support it and which don't

Browsers tend to advertise what formats they accept outside of a very basic set to the server on requests via the HTTP Accept header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

For example, Firefox on macOS sent this Accept header for this request: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8

Chrome sent text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

I would assume that’s entirely possible, but something like this could be done using the HTML5 <video> or <audio> elements for video or audio codecs (there’s even a DOM API to do it! [0]), and some browsers advertised WebP support via the HTTP Accept header [1]. For tracking, I’d assume it’s not very useful these days apart from determining who’s using Safari?

Edit: Not to mention that the onerror event handler on the <img> tag has always been able to find out if an image didn’t display [2].

[0] https://html.spec.whatwg.org/multipage/media.html#dom-naviga...

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne...

[2] https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageEl...

There is webpjs I think.

http://webpjs.appspot.com/

Basically if a browser does support webp, the script does nothing, but otherwise I think this script ends up supporting the image via javascript.

Please don’t drain my battery with crap like this when my phone has dedicated hardware for JPEG decoding.

That script won't even run unless it's on a browser which doesn't support webp.

I don't have to support ios/safari.