Crítica ao JPEG XL: AVIF já comprime melhor

Gianni Rosato publicou em 13 de setembro de 2026 uma crítica técnica detalhada ao JPEG XL. Ele argumenta que os codificadores AVIF atuais já superam o JPEG XL em toda a faixa de qualidade. O momento importa para quem publica imagens na web, porque o Firefox 157 deve ativar o JPEG XL por padrão no fim de setembro.

O JPEG XL é um formato de imagem padronizado em 2022 como ISO/IEC 18181. O AVIF é o formato rival, construído sobre o codec de vídeo AV1. Os dois buscam arquivos menores que o JPEG com a mesma qualidade visível.

Vale saber uma coisa antes dos números: Rosato trabalha no formato rival. Ele escreve que atua em compressão de imagens e que, "ao trabalhar em um codificador AV1, Julio Barba e eu fizemos o AVIF avançar de forma significativa". Ele declara isso no próprio texto. Isso não torna as medições erradas. Significa que nenhuma parte independente as verificou ainda.

O que o texto afirma

Rosato começa reconhecendo os méritos do formato. "O JPEG XL é um codec de imagem tecnicamente impressionante; é um avanço claro sobre o JPEG", escreve. A crítica é ao JPEG XL em comparação com o AVIF, não em comparação com o JPEG.

Na compressão sem perdas, ele mede o JPEG XL cerca de 11,9% menor que o WebP sem perdas em conteúdo web realista. Considera isso um retorno pequeno para o trabalho que o formato exige. Na compressão com perdas, relata que os codificadores AVIF atuais pontuam melhor em três métricas perceptuais: CVVDP, MS-SSIM e SSIMULACRA2. Essas métricas estimam o quanto duas imagens parecem semelhantes para uma pessoa, em vez de contar pixels alterados. "O AVIF agora domina toda a faixa de fidelidade", escreve.

Ele também nomeia ferramentas de compressão que o JPEG XL não tem. Não há modos de predição direcional nem filtro de deblocagem em laço. A predição direcional permite ao codificador prever um bloco de pixels a partir dos vizinhos ao longo de um ângulo, o que ajuda em bordas duras. Um filtro de deblocagem suaviza as costuras visíveis entre blocos comprimidos. A falta dos dois limita o formato em imagens não fotográficas, como capturas de tela e desenhos de linha, segundo ele.

A bomba de decodificação

A afirmação mais afiada é sobre tempo de decodificação, não sobre tamanho. Rosato descreve uma imagem construída de propósito, que ele chama de prime wall. Ela tem 1.918 bytes, e a decodificação levou 17,43 segundos de tempo de usuário em um M5 Pro. Ele escreve que "a imagem prime wall tem apenas 1.918 bytes, então vai ficar trivial bombardear com JXL os aparelhos mais fracos".

Essa é a forma de uma negação de serviço, não uma reclamação de qualidade. Um envio de dois kilobytes que custa segundos de CPU é um problema para qualquer serviço que decodifique imagens enviadas por usuários. Ele atribui a brecha ao quanto a especificação do JPEG XL é expressiva. Algumas construções são válidas e ao mesmo tempo extremamente lentas.

Ele relata mais dois achados sobre decodificação. Nos testes dele, o WebP decodifica mais de 10 vezes mais rápido que o JPEG XL. A renderização progressiva também já funciona no AVIF, e essa era uma das vantagens restantes mais claras do JPEG XL.

Os dois lados medem contra referências diferentes

O trabalho do próprio projeto JPEG XL complica o quadro da velocidade. O jxl-rs é o decodificador em Rust que o projeto diz ser distribuído tanto no Chrome quanto no Firefox. O repositório descreve o objetivo: conformidade total com a especificação, com melhor segurança de memória e melhor desempenho de decodificação que o libjxl, o software de referência oficial em C++. O projeto afirma que o jxl-rs se aproxima dessa referência e às vezes a supera, com menor uso de memória.

Essas afirmações e as de Rosato não se chocam de frente. Ele mede o JPEG XL contra o WebP e o AVIF. O projeto mede seu novo decodificador em Rust contra o próprio decodificador em C++ mais antigo. Um decodificador pode vencer o antecessor e ainda assim perder para o WebP. Lidas juntas, as duas descrevem um progresso real na decodificação que ainda não fechou a diferença relatada por Rosato.

O que isso significa para desenvolvedores

Não troque de formato por causa de um único texto. Todos os números acima vêm do conjunto de testes de um só autor, e esse autor trabalha no formato que ganha a comparação dele. A resposta certa é medir as suas próprias imagens, porque os resultados de compressão variam muito com o conteúdo.

Três coisas valem a pena neste mês. Primeiro, codifique uma amostra real das suas imagens de produção em AVIF e em JPEG XL, e anote os tamanhos em uma qualidade que você realmente publicaria. Segundo, meça os tempos de decodificação em um telefone barato, e não no seu notebook. Terceiro, se você aceita envio de imagens, coloque um limite rígido de tempo e de memória na decodificação e teste isso com um arquivo deliberadamente difícil.

O terceiro item se justifica, publique você o JPEG XL ou não. O prime wall é um exemplo em JPEG XL, mas todo codec moderno tem entradas patológicas. Um caminho de envio sem orçamento de decodificação é o defeito de verdade.

Para a maioria dos sites, o conselho prático pouco mudou desde o anúncio da Mozilla. Use AVIF para fotografias comuns e JPEG XL onde a renderização progressiva de imagens muito grandes importa. O que essa crítica acrescenta é um motivo para testar de novo esse segundo caso, porque o suporte progressivo do AVIF já não é o ponto fraco que era.