# Why one image expert gave up on JPEG XL for the web > A compression engineer who once championed JPEG XL explains why he thinks browsers still do not need it. - Title: Why one image expert gave up on JPEG XL for the web | Shortify - Summary: A compression engineer who once championed JPEG XL explains why he thinks browsers still do not need it. JPEG XL is impressive technology, but on the web it… - Keywords: image compression, jpeg xl, avif, web performance, codecs, technology, startups, one, image, expert, gave, JPEG - Source: Giannirosato — https://giannirosato.com/blog/post/case-against-jxl - Read time: 4 min - Topics: image compression, jpeg xl, avif, web performance, codecs, technology, startups ## A codec that got rejected JPEG XL is a real upgrade over JPEG and more versatile than WebP. Chrome still threw it out in 2023, and the decision stung because the format is royalty-free and backed by big names. ## A Rust decoder changed things A JPEG XL decoder written in Rust has now landed in Firefox and Chrome in some form. Memory safety answers the 2023 WebP vulnerability scare, so the old objection is weaker. ## But safety was not the only question Getting a safe decoder in the door is not the same as earning a place on the web platform. The question is whether the format actually buys the web anything. > Is this all it took to justify JPEG XL for the Web? ## Written by a former believer The author endorsed JPEG XL for Interop 2024 and knows its authors personally. He rates their conduct and technical skill, and says this piece is not an attack on them. ## He chose not to build on it After improving AVIF alongside Julio Barba while working on an AV1 encoder, he had to pick a format for his own encoder. He looked at the ceilings and passed on JPEG XL. ## The web barely needs lossless Almost every web image is served fine by good lossy compression. Average readers do not need pixel-perfect files, they need a codec that avoids ugly artifacts. ## Twelve percent is not enough JPEG XL's lossless files run only about 11.9% smaller than lossless WebP, measured on huge photos, illustrations and book scans that look nothing like web traffic. > It cannot be worth bringing a new image codec to browsers to save 12% on a tiny volume of image content ## The perceptual lead is gone JPEG XL's original pitch was an encoder tuned for human vision. libaom got perceptual tuning from controlled human trials, and SVT-AV1 has similar modes. > There is no compelling argument that modern encoders aren't tuned for the human eye. ## The metrics look grim On CVVDP, MS-SSIM and SSIMULACRA2, libjxl trails. An upcoming encoder codenamed Aperture is included to show how far libjxl sits from the frontier. ## Metrics are not that wrong Defenders say JPEG XL scores worse than it looks. The gaps here are too wide for that, and libjxl's own perceptual problems are still largely unresolved. > There's no such thing as a codec benchmark, only an encoder benchmark ## No directional prediction WebP and AVIF predict a block from its neighbours, then code only the difference. JPEG XL skips this, which costs bits and weakens edge preservation. ## Splines are not a fix The suggested replacement for directional prediction is splines. You would need an algorithm to find spline-able pixels and run every candidate through RDO, and no proof of concept exists. ## No deblocking filter JPEG XL has gaborish and an edge-preserving filter, roughly loop restoration and CDEF. Neither is a deblocking filter, and together they leave mosquito noise on the table. ## XYB oversold its gains The perceptual XYB colorspace rests on intuition and does not reliably help other formats. libjxl leans on heavy quantization of the B channel, hurting color, and new encoder authors have to undo it. ## Screenshots and art suffer JPEG XL handles non-photographic images poorly. Patches are the answer, but they drag in layers and blending, cost far more bits than AV1's Intra Block Copy, and stay off below effort 7 for speed reasons. ## The world is not vector Saying diagrams and logos should just be SVG ignores the millions that never will be, and many cannot be vectorized cleanly anyway. > “The world should be different” is not a justifiable defense against optimizing for the way the world actually is. ## AVIF wins progressive too AVIF now shows a usable image at 2 to 3% of the file, well before JPEG XL does, and the finished file is smaller. JXL needs a polyfill because even Safari skips progressive decode. ## Recompressed JPEGs cost you later Losslessly repacking a JPEG as JXL saves around 20% of the bytes. Those files then take roughly 33% longer to decode, so the saving is not free. ## Decoding is slow On size-matched encodes, WebP came in over 90kb bigger than the JXL file and still decoded more than ten times faster. AVIF already has a reputation for slow decode. > In public discourse, AVIF is considered slow to decode; what does that make JXL? ## You can build a JXL bomb A 1,918 byte JXL file that computes primes up to 33,599 takes 17.43 seconds to decode on an M5 Pro. A page full of those would stall cheap phones, and Safari already decodes JXL natively. ## Key takeaway JPEG XL is impressive technology, but on the web it now loses to AVIF on size, decode speed and safety, and its one old advantage is gone.