libjxl, the official implementation of JPEG XL, is 100k+ lines of parallel C++ that is a completely lost cause from the security perspective. It was not written with security in mind and it's going to be nearly impossible to retrofit it. There's a memory-safe implementation in Rust, jxl-oxide, but it is significantly slower than the C++ version, so much so that e.g. GNOME chose to use libjxl for performance reasons even though they're now using Rust implementations for pretty much everything else.

The good news is that Mozilla put their foot down and said they're not shipping libjxl in Firefox because of its immense attack surface, so the JPEG XL team is now working on a different Rust implementation that could potentially ship in Firefox. We'll see what comes of it and how much unsafe will it end up having.

As for AVIF, the closest thing we have to a memory-safe decoder is rav1d, which is a port of the dav1d decoder from C. It inherits the architecture of the C implementation and requires quite a lot of unsafe code.

That isn't to say that safe Rust cannot outperform C here. For example, the fastest PNG decoder in the world is written in Rust with zero unsafe blocks. But it will take a lot of effort to get there, and the much higher complexity of these recent codecs compared to something like PNG or even WebP doesn't make it any easier.