-1

i tried a few JS webp detection,

but they all always failed in safari on ios. How is this possible? I have the latest version of IOS, both Iphone 12 and 13, and friends with Iphones are reporting this as well.

Is there a problem?

For example, this function

function checkWebPSupport(callback) {
  var canvas = document.createElement('canvas');
  if (canvas.toDataURL('image/webp').indexOf('data:image/webp') === 0) {
    // WebP is supported
    callback(true);
  } else {
    // WebP is not supported
    callback(false);
  }
}

// Usage
checkWebPSupport(function(supported) {
  if (supported) {
    console.log("WebP is supported");
  } else {
    console.log("WebP is not supported");
  }
});

Can anyone advise me what really works?

Mr. RJ
  • 224
  • 5
  • 14
  • According to https://caniuse.com/mdn-api_htmlcanvaselement_todataurl_type_parameter_webp toDataURL is not supported in Safari/IOS. It doesn't mean that webp isn't supported for other use. – A Haworth Jun 26 '23 at 16:52
  • Oh, good point. I will search better approach how to handle it. Thx. – Mr. RJ Jun 26 '23 at 17:05
  • Yes, it's not because a browser can decode a file format that it also has an encoder. As for testing for webp support... the thing is webp has many features that not all browsers did support from the get go (e.g animations, lossless, or alpha). So if you wanna test if a browser support this file, you unfortunately have to test using the actual file you wish to display... Fortunately though, this should concern less and less users as the format has reached a better browser support since quite some time now. – Kaiido Jul 04 '23 at 03:10

1 Answers1

-2

I’ve not personally done this, but it seems like the “Accept” header in a request sent from the browser would be able to reliably tell you if the browser supports it. It doesn’t feel super clean, but you can make it work by sending a request to nowhere and then reading that header. Others have posted about this:

https://stackoverflow.com/a/51842418/3644967

That said… are you sure you need to check for it at all? .webp support is really, really good these days. I would just assume every browser you care about can handle it. I just launched an image optimization/reformatting service, and I’ve even decided to make .webp my go-to target for image formats, it’s just that ubiquitous:

https://picperf.dev

Alex MacArthur
  • 2,220
  • 1
  • 18
  • 22
  • The answer you linked to will get the Response headers, not the Request's ones, plus browsers generally send `Accept: */*` (at least as the last preferred value). So the absence of a MIME type doesn't say anything. – Kaiido Jul 04 '23 at 03:04
  • Shoot. My mistake. Well, assuming you could get access to the request headers, I’m fairly confident from past experience that browsers would send more than just */*. I believe I’ve seen other tools know which formats are supported by parsing that header. – Alex MacArthur Jul 04 '23 at 05:00
  • This will depend on which request is made, and they'll just send their preferred mime, not all that they support. For instance, with a simple `fetch()` (or XHR), you'd get just `*/*` because the browser doesn't know what you want to do with the resource. From an `` tag, they'll send their preferred image MIME types, so e.g. on my current Firefox it's `image/avif,image/webp,*/*`. If we were to rely only on that header we'd be assuming `image/png` isn't supported, which is completely wrong. – Kaiido Jul 04 '23 at 05:06