Here we are, 2026, and brand new software like Lemmy:
Doesn’t support AVIF
Doesn’t support JXL
Doesn’t support WebP
Won’t upload short, small videos either.
Meanwhile:
Many clients won’t play animated WebP
Most clients won’t play APNG
Many won’t load AVIF
Basically only Apple/Safari will load JXL
VP8/VP9/AV1 support in video isn’t universal
What am I supposed to do?
I used to send support requests over this, but I’ve given up. We are going to be stuck with SDR JPEGs and blocky GIFs forever, especially since media format literacy seems to be globally.
You decide what to target, and work with what you have. That’s how it’s always been with web technology.
If you need to support the barest minimal possible clients then you might not even have HTML5. Otherwise, if you have HTML5 you can use the source tag to provide clients with a choice of formats/encodings and they can pick the one they support. If the clients can’t even mange that, well, things on the internet have always been broken anyway.
And somebody’s gotta start somewhere, WebP was shoved down everyones’ throats and now it’s supported very broadly, as AVIF pick up users software devs will take notice and start supporting it.
I cite Lemmy again. This is supposed to be a newer, better version of Reddit, basically, but I can’t even upload a WebP to my instance… when are they supposed to adopt AVIF?
If I try to host externally, which is more of a pain, very few image hosts will take an AVIF. Not a single one I found except catbox will take a JXL.
Where’s the pressure? Who’s making these files and trying to use them? Even my phone converts uploaded JXL and HEIF files to SDR JPEGs upon upload, since it rightfully assumes nothing will work with them.
I hate to sound so cynical, but I had your mindset a while back. And outside Apple, precisely nothing has changed. Its gotten more dramatic, if anything, since HDR support is now basically DOA too.
Where’s the pressure? Who’s making these files and trying to use them?
The standards bodies and the companies that pay their bills. That’s Netflix, Google, et al. All have a vested interest in good multimedia support in browsers. It’s why browsers have shockingly good support actually, most of the problems are downstream on clients and implementations that don’t know or care to enable these newer formats.
I used to love optimising images in gif format. I would make like 4–30kb memes and animations for my friends in Photoshop CS2. It’s actually extremely efficient and lightweight if you do it right… You have cool tools like transparency between frames and unbroken colour blocks don’t take any additional storage space. There’s nothing wrong with gif.
The problem is how people use them. We take a live action video file and shove it through an automated converter tool that doesn’t give a shit about efficiency and will do a complete repaint between frames and use 256+ colour palette. Then you end up with an ugly dithered overcooked piece of shit 50mb 10 second animation. Gif was not designed for this…
Discord, Signal and Whatsapp all let you send any video format I’ve ever tried. I presume the same is true for Messenger and whatever else people use to communicate nowadays. I genuinely can’t think of anything that would support GIF but not various video formats.
That works out if you’re from Europe or somewhere else where using third party messaging apps is common but in the US we primarily use text messaging apps which don’t really support webm or avif
Can just use avif instead, it holds an AV1 stream and acts like gifs/images do WRT looping — also very broad support (more than AV1 in WebM containers).
Demonstration:
Edit: switched to an example with simpler decode requirements.
I checked that app’s source code, and basically they’re doing their own avif decode call instead of relying on a browser/webview to handle it. So essentially they forgot/don’t know/don’t intend to implement animated avif. Looks like they also use the aom reference decoder instead of using something faster like dav1d.
I do regularly. However apple users are largely the bane of this. Apple’s support for things can be very slow and spotty. As long as you keep it extremely old and basic. Say h264 they’ll be able to see. A lot of apple mobile devices could support h265 but apple doesn’t. My last couple of mobile devices have supported it for nearly a decade. But apple enabling it on their mobile hardware hasn’t been anywhere near that long. Apple will hopefully have AV1 support common by the time AV3 is released and AV2 widely supported by the 2030s.
Oh yes with respect to Avif you are correct. I was more referring to multimedia messages in general. But you are correct about Avif. That format in particular is not well supported a lot of places. I know Linux is probably one of the few areas it sees much. Windows is a much different story and I’m sure Apple desktops as well.
(on Arctic on ios) the uploaded image displays as a static image for me. Even clicking on it and waiting, it doesn’t seem to animate :T
Edit: I checked again through the Voyager app, and it did indeed load, though it took around 45-60 seconds* for it to get through the entire animation before it started looping again, albeit at the same speed as the first playthrough.
I chalked it up to the outdated hardware, as you mentioned in your reply. Cheers! :)
Apple has limited support for AV1 streams (yes, even for software decode) unless on very recent hardware.
Here’s an AV1 stream inside a webm container for comparison, would be interesting to see if that works over the avif container on your stack.
Ah yeah, that would explain it - my phone is now pretty outdated (I’m on a 12) - I clicked on the image link in your response but it didn’t load for me, unfortunately.
I’m not sure if that’s a result of my outdated hardware or if I perhaps clicked on it before it had a chance to process your upload, but you seem much more knowledgeable than I, so I’m going to assume it’s my hardware. I appreciate the response and the second attempt, though! :)
It’s an intentional behavior by Apple. Basically they just don’t support AV1 videostreams unless the hardware you’re using has a hardware decoder (read: very new). They could support it using software decode (what browsers typically do for AV1 inside avif containers) but… for whatever reasons don’t.
Sadly no. Most browsers don’t render static JXL by default yet. Let alone animated. I wish they would. Though for most things regular video transport streams will usually be as good or better. Honestly at this point animated image formats really are kind of a niche and not necessarily super useful at this point. Apng for instance when it was created nearly 20 years ago made some sense. Today now that it’s finally getting supported it doesn’t make as much sense.
I mean, we don’t really need a browser to render it in order to make a performance comparison. But hey, Firefox is getting support for JPEG XL? So there’s that, I guess.
No you’re fine. I just wanted to be clear that until it’s default it may as well not be there. Outside of my own personal pet projects. No one else would see them that visited unless it was enabled by default generally and therefore not very useful still. I don’t know how much longer it will take them to enable it by default. I hope not much longer. I generally like jxl.
I would argue and say that it is poor implementation on your developers behalf, Lemmy itself supports it, your client is failing to properly render the image.
As mentioned previously, Voyager displays the image as intended.
Please stop making gifs at all. It’s a terrible format that creates massive files that look like shit.
Webm is supported almost everywhere now and manages better quality at higher framerates and smaller file sizes.
I’ve honestly given up on support of new formats.
Here we are, 2026, and brand new software like Lemmy:
Doesn’t support AVIF
Doesn’t support JXL
Doesn’t support WebP
Won’t upload short, small videos either.
Meanwhile:
Many clients won’t play animated WebP
Most clients won’t play APNG
Many won’t load AVIF
Basically only Apple/Safari will load JXL
VP8/VP9/AV1 support in video isn’t universal
What am I supposed to do?
I used to send support requests over this, but I’ve given up. We are going to be stuck with SDR JPEGs and blocky GIFs forever, especially since media format literacy seems to be globally.
You decide what to target, and work with what you have. That’s how it’s always been with web technology.
If you need to support the barest minimal possible clients then you might not even have HTML5. Otherwise, if you have HTML5 you can use the
sourcetag to provide clients with a choice of formats/encodings and they can pick the one they support. If the clients can’t even mange that, well, things on the internet have always been broken anyway.And somebody’s gotta start somewhere, WebP was shoved down everyones’ throats and now it’s supported very broadly, as AVIF pick up users software devs will take notice and start supporting it.
Will they, though?
I cite Lemmy again. This is supposed to be a newer, better version of Reddit, basically, but I can’t even upload a WebP to my instance… when are they supposed to adopt AVIF?
If I try to host externally, which is more of a pain, very few image hosts will take an AVIF. Not a single one I found except catbox will take a JXL.
Where’s the pressure? Who’s making these files and trying to use them? Even my phone converts uploaded JXL and HEIF files to SDR JPEGs upon upload, since it rightfully assumes nothing will work with them.
I hate to sound so cynical, but I had your mindset a while back. And outside Apple, precisely nothing has changed. Its gotten more dramatic, if anything, since HDR support is now basically DOA too.
The standards bodies and the companies that pay their bills. That’s Netflix, Google, et al. All have a vested interest in good multimedia support in browsers. It’s why browsers have shockingly good support actually, most of the problems are downstream on clients and implementations that don’t know or care to enable these newer formats.
I used to love optimising images in gif format. I would make like 4–30kb memes and animations for my friends in Photoshop CS2. It’s actually extremely efficient and lightweight if you do it right… You have cool tools like transparency between frames and unbroken colour blocks don’t take any additional storage space. There’s nothing wrong with gif.
The problem is how people use them. We take a live action video file and shove it through an automated converter tool that doesn’t give a shit about efficiency and will do a complete repaint between frames and use 256+ colour palette. Then you end up with an ugly dithered overcooked piece of shit 50mb 10 second animation. Gif was not designed for this…
Problem is the medium people use to send GIFs to each other doesn’t support any alternatives
Discord, Signal and Whatsapp all let you send any video format I’ve ever tried. I presume the same is true for Messenger and whatever else people use to communicate nowadays. I genuinely can’t think of anything that would support GIF but not various video formats.
That works out if you’re from Europe or somewhere else where using third party messaging apps is common but in the US we primarily use text messaging apps which don’t really support webm or avif
Counterpoint: GIFs loop by default in basically every app, WEBM doesn’t
Can just use avif instead, it holds an AV1 stream and acts like gifs/images do WRT looping — also very broad support (more than AV1 in WebM containers).
Demonstration:
Edit: switched to an example with simpler decode requirements.
Thanks for bringing this format to my attention. I opened it in a browser and it’s pretty sweet.
Hopefully app support will grown over time… Otherwise it’ll be .gif 'till the end.
Your demonstration is a sluggishly loading static image on my end, so I guess support isnt that widespread :P
(Im using the app “Summit”)
I checked that app’s source code, and basically they’re doing their own avif decode call instead of relying on a browser/webview to handle it. So essentially they forgot/don’t know/don’t intend to implement animated avif. Looks like they also use the aom reference decoder instead of using something faster like dav1d.
Static image, Eternity.
Static image, also Summit.
Does not work on Voyager for Android, the humble inefficient GIF continues in spite of more efficient options
Your example image doesn’t work in boost while the gif above does :/
Boost for Lemmy is not a fan.
That’s caused by bad regex in the app, it’s getting confused about domains.
e: attempted fix by using an aliased domain.
Works great as a static image. Would probably be better if it actually played…
Lemmy won’t even upload AVIF files
As you can see below, it won’t play back for many users…
It’s unfortunately not that simple. The AVIF doesn’t load at Jerboa, for example :/
your demo is a static image.
Using a browser or third party app?
Summit Android app.
Let me know when I can text one of these to someone
I do regularly. However apple users are largely the bane of this. Apple’s support for things can be very slow and spotty. As long as you keep it extremely old and basic. Say h264 they’ll be able to see. A lot of apple mobile devices could support h265 but apple doesn’t. My last couple of mobile devices have supported it for nearly a decade. But apple enabling it on their mobile hardware hasn’t been anywhere near that long. Apple will hopefully have AV1 support common by the time AV3 is released and AV2 widely supported by the 2030s.
Apple only supports avif on paper and doesn’t actually support avif in iMessage in practice. It won’t display properly and they don’t care to fix it.
On the Android side Google Messages Doesn’t appear to support avif at all
Oh yes with respect to Avif you are correct. I was more referring to multimedia messages in general. But you are correct about Avif. That format in particular is not well supported a lot of places. I know Linux is probably one of the few areas it sees much. Windows is a much different story and I’m sure Apple desktops as well.
(on Arctic on ios) the uploaded image displays as a static image for me. Even clicking on it and waiting, it doesn’t seem to animate :T
Edit: I checked again through the Voyager app, and it did indeed load, though it took around 45-60 seconds* for it to get through the entire animation before it started looping again, albeit at the same speed as the first playthrough.
I chalked it up to the outdated hardware, as you mentioned in your reply. Cheers! :)
Apple has limited support for AV1 streams (yes, even for software decode) unless on very recent hardware. Here’s an AV1 stream inside a webm container for comparison, would be interesting to see if that works over the avif container on your stack.
This doesn’t work for me but the original one you posted does (Voyager, iPhone 14 pro)
Very interesting, thank you!
Random Android phone on Voyager; yes.
Ah yeah, that would explain it - my phone is now pretty outdated (I’m on a 12) - I clicked on the image link in your response but it didn’t load for me, unfortunately.
I’m not sure if that’s a result of my outdated hardware or if I perhaps clicked on it before it had a chance to process your upload, but you seem much more knowledgeable than I, so I’m going to assume it’s my hardware. I appreciate the response and the second attempt, though! :)
It’s an intentional behavior by Apple. Basically they just don’t support AV1 videostreams unless the hardware you’re using has a hardware decoder (read: very new). They could support it using software decode (what browsers typically do for AV1 inside avif containers) but… for whatever reasons don’t.
Haha, ye$, for rea$on$, I’m $ure… :D
I’m not sure demand for AV1 is enough to ship units
Probably either laziness or they want to avoid software decoding in general for performance reasons
an Osman classic
Fwiw it works on the desktop’s alexandrite ui and on the thunder app
For the record, this is static in my Lemmy app (Summit).
on boost its a little slow but time quality.
better than most moving images in comments!
Anybody who has compared animated WebM vs animated JPEG XL?
Sadly no. Most browsers don’t render static JXL by default yet. Let alone animated. I wish they would. Though for most things regular video transport streams will usually be as good or better. Honestly at this point animated image formats really are kind of a niche and not necessarily super useful at this point. Apng for instance when it was created nearly 20 years ago made some sense. Today now that it’s finally getting supported it doesn’t make as much sense.
I mean, we don’t really need a browser to render it in order to make a performance comparison. But hey, Firefox is getting support for JPEG XL? So there’s that, I guess.
Eventually. They’ve been dancing around it for a long time. Google tried to kill it.
It’s already in Firefox 152 behind a switch. 👍
Yes, just not enabled by default.
That’s what I meant by “behind a switch” 😅, sorry if that was unclear.
No you’re fine. I just wanted to be clear that until it’s default it may as well not be there. Outside of my own personal pet projects. No one else would see them that visited unless it was enabled by default generally and therefore not very useful still. I don’t know how much longer it will take them to enable it by default. I hope not much longer. I generally like jxl.
Couldn’t APNG be considered?
I wasn’t even aware of APNG or AVIF before this thread. Webm was just the first alternative for GIFs that came to mind.
Looking at this APNG also seems to result in pretty large files whereas AVIF appears to have by far the best compression.
AVIF looks like the best alternative for sending short meme clips to people, which I assume is most peoples use case for GIFs.
that’s a static image. not at all animated.
perhaps if you open the Wiki link where the image was taken from, for me it’s animated on Voyager.
my lemmy client doesn’t support opening arbitrary web pages
which is my entire point: your proposal is dead in the water as it doesn’t work universally.
I would argue and say that it is poor implementation on your developers behalf, Lemmy itself supports it, your client is failing to properly render the image.
As mentioned previously, Voyager displays the image as intended.
I thought the file size was part of the format specification, no?
Yes? I don’t really understand the question.