Avif format is not supported

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [x] Documentation issue or request

Current behavior


The documentation suggests that assets can be delivered in avif format. But I saw a message that it has been disabled because it would be too slow. My preference would be avif over webp if supported. So I hope this will be added in the future

Expected behavior

?auto=true delivers avif format


App Name:

  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x] Cloud version

Does this functionality have priority on the backlog or should I not expect it soon?

this is a little bit out of control. I will measure the performance again, but I depend on third party libraries here.

I just realized that it seems to be a general thing:

From https://avif.io/blog/faq/avif-downsides/

AVIF (AV1 Image File Format) is a modern image codec that has gained widespread adoption due to its high compression rate and support from a wide range of applications. However, there are also some downsides to using AVIF that should be considered when deciding whether it is the right choice for a specific use case.

One of the main downsides of AVIF is that encoding and creating AVIF images takes longer compared to other image formats. This can cause problems for sites that generate images dynamically, as the longer encoding time can result in delays. The AVIF team is working to improve the speed of encoding, but it is currently an issue to consider.

Another potential downside of AVIF is that it is not optimized as a single image format, as opposed to JPEG XL. Since AVIF is derived from the AV1 video codec, some critics argue that it is not optimized specifically for still images. This can result in less efficient encoding and potentially lower image quality compared to formats that are designed specifically for still images.

Additionally, images encoded with AVIF may draw more CPU power to display compared to images encoded with other codecs. This can impact the performance of applications that display large numbers of AVIF images, particularly on devices with limited processing power. However, the impact of this may be compensated by the size of the image, with smaller images having a lesser impact on performance.

Finally, it’s worth noting that support for AVIF is not universal. While 70% of current browsers can view AVIF images, not all programs currently support it, including Adobe Photoshop. This can limit the use of AVIF in certain situations where compatibility with specific software is required.

Overall, while AVIF has many benefits, it is important to carefully consider these downsides when deciding whether it is the right choice for a specific use case.

Sebastian, just curious about whether you’ve had time to do some more testing?

For me and for the project that I’m currently building having .avif would make a lot of sense:

  • AVIF compresses so that files become 20% smaller than WebP. Components: <Image> | Next.js Even though storage is cheap I would cut down on cost. I use several services (MongoDB Atlas, Clerk, Algolia, Azure, Vercel, etc.) and combined they add up to the total cost)
  • Performance - users would be able to receive image files faster which in turn leads to a better user experience.
  • All major browsers support it except Edge (you need to enable support via a flag)
  • If you use a service provider like Cloudinary, Cloudflare, etc to serve your images the compute will happen on their servers and not on Squidex.
  • Next.js supports AVIF out of the box. Components: <Image> | Next.js which is what I’m currently using as head/front-end for Squidex.
  • By adding AVIF support to Squidex we’re contributing to a better and more modern web and it also gives Squidex a competitive edge.

So to conclude I think those paragraphs in What are the downsides of AVIF? | avif.io ✨ are not enough for not having AVIF support in Squidex IMO.

Not recently tbh.

The problem with “auto” is that it would trigger hundred thousand image reformats at once, which could become a problem as well. I think I would need to move the image resizer service to a serverless deployment first.


What do you mean by “reformats”?

Lets say I would enable avif, then all images that would be delivered as webp would probably be delivered as avif automatically then. So many images need to be reformatted in avif then.

I uploaded an .avif file to Squidex just to test it and it allowed it. So Squidex HAS support for .avif? :thinking:

I’m on Squidex 7.8.2 btw.

Oh, now I see. You’re referring to the cloud version.
I was talking about Squidex in general.
Well in that case it makes sense then.

But for self hosted it is fine to use .avif however you want, correct?


it would be perhaps better to introduce an option instead of a compiler flag:

Saw that yesterday actually.
Also checked application.json, thought it might be there somewhere but it was not :slight_smile:
Yes, maybe making it optional in the app settings would be a good idea.

BTW, what is the ?version=0 that gets added to all image URLs? I’ve always wondered :slight_smile:
Is it for cache busting?

It is the file version. If you replace the asset with another version you can also request that by appending the version.

1 Like

Hi @Sebastian
Show question. Does squidex cache images after conversion or Is there a conversion every request to get image?
If we using CF and we have cache policy, so it will not allow us return image based on accept header?