We don’t have an error number.
One of our customers if reporting seeing glitched images hosted on Images. He’s using Safari 16.6.1 in macOS Big Sur.
I am not aware if this can be disabled, since this option is enabled by default if the detection of Web browser supports such format.
Have you tried using format=jpeg parameter specifically? 
Furthermore, by default images that cannot be compressed as AVIF will be served as WebP instead.
Yes, but it seems this doesn’t work with images stored in Cloudflare Images. From the docs you linked:
At the moment, this setting only works directly with image transformations.
The docs explain that transformations:
Transformations let you optimize and manipulate images stored outside of the Cloudflare Images product
Anyway just to confirm I enabled flexible variants and added the format=jpeg parameter to the URL. Still the served image comes with this header content-type: image/avif.
See this image for example:
https://imagedelivery.net/EMcgC0ee0hgRK9GzM3ap1w/c3a1b8d6-e662-4b96-05e4-3b6d50555900/format=jpeg,width=250
The width parameter is being applied but the format parameter is being ignored.
Thank you for feedback.
In Firefox, as jpeg:
While in Chrome as avif:
Are you on a paid plan?
Wonder if you could manage to serve only WebP for instance and can you try to serve it with filename as .jpg as well?
I am afraid this might be by default. I can see using search 
there are topics about the same issue happening to others.
May I ask have you considered serving them via Cloudflare R2 product and using custom sub-domain such as images.mydomain.com instead?
Thanks for your help @fritex .
Yes. Both on the Cloudflare plan and Cloudflare Images.
This is a config for the CDN on our domain which I’m not using (images are served from the imagedelivery.net domain).
Yes I could host images anywhere and use the CF CDN but CF Images takes care of different variants, storage, etc.
Probably because FF is not sending image/avif in the request accept header (not because of the format=jpeg setting).
I checked and Safari 18.3 is not sending it either. Maybe the issue our customer is seeing is not related to webp of avif after all… hmmm I’ll have to see the headers their version.
Thanks again for your help.
I can’t test, since I don’t have that setup, and BrowserStack doesn’t go beyond 14.1 on Big Sur.
All documentation indicates that should work:
Have they been able to try a different browser on Big Sur?
Yes but that’s no guarantee. I’ve personally seen FLAC audio files failing on Safari in versions where it’s theoretically supported. Reported the bug to Apple and turned out to the a macOS issue.
Anyway, if you read my previous comment I’m not sure if Safari is actually receiving AVIF or WEBP now and I’ll need to confirm with our customer.
The challenge is that Images URLs don’t have extensions, so browsers aren’t sending image-specific Accept headers, which eventually fall back to */*.
It sounds like Cloudflare is sending formats that should be compatible with the browser, but if it’s not, then that may be an issue that Cloudflare Images devs could assist with.
Yep, but it helps to look at it from several angles, including different browsers.
Our customer has confirmed he’s not receiving an AVIF or WEBP image… so I’ll close this thread since the issue is not caused by this.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
