The site claims that animated WebP might be fully supported - but while writing a Obsidian-to-Static site exporter that would compress animated GIF file to animated WebP, I found that Webkit-based browsers seem to struggle with fluid playback particularly on iOS.
Basically use webp if you want to have the fewest problems while still retaining the majority of benefits out there. Good compression, works across most devices, and unexpected pitfalls like animating transparency aren't an issue.
Pardon my pedantry but MP4 is just the container and does not spare you from finding a compatible set of codecs to put in that container that will play on your target browser-plus-OS combo. See the video and audio codec table here for example: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Fo...
I stumbled over that 19% in the article. Maybe in practice you wouldn't want to convert a GIF to lossless webp, but original video to lossy webp? And then the lossy webp would be slighly smaller than the GIF with far superior quality?
<video> and mp4 can also work well. As a GIF replacement, the initial differences are minor because you can easily add loop and autoplay to the video’s attributes, and both work with most browsers’ reader modes. From my tests, though, video-as-GIFs isn't a feature supported by the major RSS readers, while WebP works without any issues.
Anyways, the real insurmountable problem is animations with transparent backgrounds. There’s no good way to do this in mp4, and WebP seems to be the only format that does it well. But because of all the little pains, headaches, and surprises that can arise due to subtly different use cases, I still think WebP is the format that will give you the most benefit with the least drawbacks for silent animated images. Even without having transparent backgrounds as a requirement.
MP4 is just a container format (like .tar or .zip in some ways). The video codec is more important information than the video/audio/subtitle container.
Agreed with the MP4 recommendation. As I mentioned in another thread, animated WebP can have frame-rate issues on Safari... but if you want autoplaying videos with transparency it's pretty much the only game in town.
If you don't need transparency, I would 100% stick with mp4. Just make sure you set the tag elements "autoplay loop muted".
Mobile Safari used to be pretty weird. If you wanted autoplay (and NO controls), you needed to make sure to remove the audio channel on the video. Setting the "muted" attribute wasn't enough.
We should probably stop using GIF format in 2025. Browsers still play gifs and animated WebP right on page load, which is distracting and uses a lot of network bandwidth. All animated content should adhere to "Block autoplay" setting in the browser, not only video files.
Replacing gifs with video files does come with an increased the risk of malware being spread. If it gets common to stuff webpages full of video files we should expect to see an increase in the use of malicious video files to do bad things.
In my case, as someone who doesn't allow javascript by default and prevents media from playing automatically the only image on that entire page that loaded for me was dancingbaby.webp
Everything else (if it showed up at all) displayed as generic blocked elements I'd have to click on to view (or right click to download) so if that catches on websites that are currently busy with gifs should load a lot faster and look a lot cleaner. That's a plus.
Time to block webp by default too. It's still a way too immature format to be relied upon. In fact it already was exploitable (via libwebp), AFAIR. :^)
i don't understand how one thing leads to another. if anything, a popular feature (videos) is more protected against 0days as there's more eyes on it, not the opposite. what else could a "malicious video file" be, a cognitohazard? i am aware of the facebook tails video 0day but that's not a browser issue, nor is it a common issue
> if anything, a popular feature (videos) is more protected against 0days as there's more eyes on it, not the opposite.
It's usually the opposite. The more common something is, the more likely attackers are to target that thing. Adobe acrobat was a prime target for malicious PDF files because it was what everyone used. Once browsers started displaying PDF files attackers turned their attention there.
Ultimately every exploit that gets discovered does result in increased security, as bad code gets patched, but there's no shortage of bad code and even long lived codebases get new flaws discovered all the time.
> what else could a "malicious video file" be, a cognitohazard?
malicious video files usually target whatever software processes them.
WebP might support GIF-like animation, but since it's just one feature of an incredibly-complicated codec it invites a huge attack surface with extremely wide range since 99% of people will use libwebp. GIF89a on the other hand is simple enough that lots of people can write a working decoder.
It's happened multiple times over a large number of formats. Even gifs have been exploited (https://www.zdnet.com/article/whatsapp-vulnerability-exploit...), but just as you said it's the complexity of video that makes it more difficult to keep secure.
Are the features and codecs safari doesn't support part of WebKit? If so does that mean that any browser on iOS doesn't support it either?
Also, the article links to a blog post[0] about video with transparency, and although the performance is the main complaint I had no idea this was a thing! Worth the read if you enjoyed the article I think.
Nope, it's implemented in the browser engine. I honestly find it funny that, for example, Opera, Edge and Chrome are supposedly different browsers, even though it's all actually Chromium and there is no meaningful difference.
Gifs kind of became irrelevant when most platforms started autoplaying video muted by default. What was a gif is now just a video without sound. Format doesn't really matter.
I re-encoded all of my webm's to mp4's back then on my "gif blog", thanks to Safari and all my mac-using friends saying "I can't see it". Now look who started to support it eh.
From a brief test, at least some of the options on the page do support save-able single file--depending on the browser (e.g. desktop Firefox with right-click).
It is unfortunate that few, if any, of the commercial "GIF host" services or social media sites made any attempt to preserve the single file nature of the GIF with their "more efficient" replacements. Of course, in many cases this was intentional because they wanted to require people to use the company's web site as the "player".
Even more so, it has long bugged me that none of the attempted "replacements" have made any attempt to make use of the inherent extensibility of the GIF format itself to support transitioning to a more efficient format while also preserving the single file nature of the GIF and supporting "legacy" GIF-only clients.
The GIF format's extensibility was how GIFs gained the ability to loop, after all.
----
The GIF format could've been used to support transitioning to a more efficient format.
The key observations to make were:
(1) A GIF image sequence when converted to an efficient compressed video format occupied only small fraction of the original GIF.
(2) Thus a compressed video variant of the GIF could be appended to the original GIF file and the overall file size wouldn't be "significantly" larger than the original GIF.
(3) But even better thanks to GIF's extensibility via "Application Extension", rather than appending, the video data could "transparently" be embedded into the GIF (with a small size efficiency loss) and thus the file could be downloaded, transported & "legacy" visuals displayed by existing tools--without loss of the embedded compressed video variant's data.
(4) The last piece of the puzzle is that if we, say, also include a size value N in the second-to-last block of the GIF (with some fixed-byte-size per format version) then "NuGIF"-aware (or whatever :) ) client software (or, e.g. a JavaScript shim) could perform a HEAD request for total file size, followed by range-request of the second-to-last block, followed by range-request of last N-ish bytes to download just the bytes of the video encoded version. And "legacy" clients wouldn't be particularly "significantly" burdened by the additional video variant bytes contained with in the GIF.
But, ya know, nobody did. :)
(Obviously there's also the opportunity for a "more efficient" but "less ideal" variant of the concept such as simply embedding an alternative video URL in the GIF instead but that wouldn't be nearly as cool. :D )
Of course, one obvious risk with a "dual content" format like this is that it would be possible for the GIF-encoded visual content to not match the video encoded visual content--as is already the case with e.g. embedded image thumbnails. (I've vaguely contemplated how the consistency might be verified with "untrusted sources" in some way based on--some portion of--actual visual content but... *shrug*)
Anyway all that has always just been a concept but...
...of course, we've just been ignoring the elephant trumpeting in the room...
...the reason I started digging into the GIF format in the first place...
...the thing that's always been missing from GIFs...
[Spoiler alert: Just noticed, apparently, Web Audio API policy changed again at some point, so you may get `AudioContext` console message spam. :/ Guess that's web development for you--these days I normally let Godot handle it for me. :D The demo reel sequence used to only require a click on the first image...]
[Note: Just looked at the code & apparently past me never got around to making "Save Image As..." work when on a demo reel page but "Save Link As..." should work. :)]
[Also, No Spoilers but seriously what are the odds of me hearing this specific line being uttered "on air" during the time I was working on this project: https://audiogif.rancidbacon.com/three/ ?! :D ]
----
My Audio GIF project remains one I'm particularly proud of--in part just because I did actually release the thing; and, then, I guess I just really like lower-level hacks that serve no practical purpose but challenge "assumed wisdom"? :)
Oh, yeah, and part of the motivation for completing the project was the existence of a Reddit thread many years prior where I saw someone get almost totally mocked for having the audacity to ask whether it was possible for a GIF to have audio--to which the answer was a resounding (yet incorrect): No!
(Which I already knew at the time was entirely possible in theory.)
To their credit, I do recall there was one person who was brave enough to comment that it was a theoretical possibility.
So, for years after I assumed someone would surely create such project.
And, eventually, when someone didn't, I did. :)
----
One thing at the time that was cool was I discovered that some GIF hosting services that provided access to an actual GIF file also didn't strip unknown "Application Extension" blocks from the GIF file--so the audio in the GIF was preserved!
Unfortunately one thing at the time that was uncool was I discovered it was during a window of time when Range Requests required CORS--a restriction I think was eventually removed as unnecessary--but as a result I didn't upload a public demo that used an Audio GIF stored on one of the standard GIF hosts.
----
Obviously the Audio GIF format didn't exactly... set the world on fire at the time but that's okay because according to the linked article GIFs are "‘for boomers’ and ‘cringe’" anyway.
But... in twenty-five years time, when streaming isn't cool and vinyl isn't cool and camcorders aren't cool and when even audio cassettes are uncool again... well, the Audio GIF will be there waiting...
Waiting for someone to innocently ask: "Can GIFs have audio?"...
Waiting so a small voice can cut through the raucous laughter and say: "Well, ackchyually..."...
And, then, my work will be complete. :D
----
Too Long; Did Epilogue:
As a lesson for us all, perhaps the most amusing part of the whole project occurred when, having finally released everything, I posted one of the demo Audio GIFs to /r/gifs...
...only to have the mods reject the submission because... "it isn't a GIF" ...because... "GIFs don't have audio" ...despite literally being a GIF file! :D
Turns out, somewhere along the line, apparently "GIF" stopped being a specific file format and instead became a category referring to any short looping image sequence without sound--whatever the file format. :D *shrug*
skinner-out-of-touch.not.a.gif
----
Anyway, apparently this is my "How to GIF (2025 Edition)" article, so if you made it this far: thanks for reading. :)
Example here:
https://gondolaprime.pw/animation-test
reply