O Chrome 155 ativa o JPEG XL por padrão

O Chrome 155 decodifica imagens JPEG XL por padrão, anunciou a equipe do Chrome no Google em 6 de outubro de 2026. O decodificador é o jxl-rs, escrito em Rust para garantir a segurança da memória. Como o Firefox 158 deve seguir em 13 de outubro, o JPEG XL está prestes a funcionar em todos os principais motores de navegador. Isso encerra um desvio de quatro anos para um formato que os desenvolvedores web não paravam de pedir.

O que o Chrome entregou

O JPEG XL, com extensão de arquivo .jxl, é um formato de imagem criado para substituir o JPEG. Ele pode guardar fotos em tamanhos menores e também pode reempacotar um JPEG existente sem perder qualidade alguma.

A equipe do Chrome lista os recursos que ele aceita:

• compressão com e sem perdas
• HDR, ou alto alcance dinâmico, para realces mais brilhantes e sombras mais profundas
• transcodificação JPEG sem perdas, que reduz um JPEG antigo e pode devolvê-lo ao original exato
• decodificação progressiva, que mostra primeiro uma versão aproximada da imagem e a deixa mais nítida conforme chegam mais dados
• animação

De acordo com o CoreWebVitals.io, o formato chegou ao Chrome 145 em fevereiro de 2026, atrás de um flag em chrome://flags/#enable-jxl-image-format. O Chrome 155 elimina a necessidade do flag.

Por que o decodificador é escrito em Rust

Decodificadores de imagem são um alvo clássico de atacantes. Um bug no código que descompacta uma imagem pode deixar uma imagem armadilhada tomar conta de um navegador. A equipe do Chrome chama os decodificadores de «uma das superfícies de ataque mais críticas e mais visadas em qualquer navegador web moderno».

Por isso ela escolheu o jxl-rs, um decodificador escrito do zero em Rust. O compilador do Rust bloqueia classes inteiras de bugs de memória que C e C++ permitem. A equipe também criou o jxl_simd, uma camada SIMD inspirada na biblioteca Highway do Google. As instruções SIMD permitem que um processador trabalhe com muitos pixels de uma vez, o que mantém o código seguro rápido.

A equipe do Chrome diz que o fuzzing e a revisão de código por IA não encontraram bugs de segurança de memória durante o trabalho. O fuzzing consiste em lançar milhões de entradas aleatórias contra o código.

Os relatos divergem sobre a velocidade. O CoreWebVitals.io diz que o jxl-rs roda a 15-25% do decodificador de referência em C++. O Fileza coloca a diferença em 5-10%.

Por que o Chrome mudou de ideia

O Chrome já havia abandonado o JPEG XL antes. O Fileza chama isso de «a controversa remoção de 2022». A equipe do Chrome agora diz que agiu a partir de «feedback e pedidos constantes de desenvolvedores web». Ela aponta a popularidade do formato nas propostas do Interop Project, em que os fabricantes de navegadores combinam a cada ano as lacunas que vão corrigir juntos.

A volta segue uma longa história. A Mozilla anunciou em agosto o suporte ao JPEG XL com seu próprio decodificador em Rust. O jpegxl.info agora lista o Firefox 158 como o que o ativa por padrão, previsto para 13 de outubro de 2026.

Navegador	Situação do JPEG XL	Fonte
Chrome 155+	Ativado por padrão	Equipe do Chrome, jpegxl.info
Chrome 145-154	Atrás de um flag	CoreWebVitals.io
Firefox 158	Ativado por padrão, previsto para 13 de outubro de 2026	jpegxl.info
Safari 17+	Com suporte desde setembro de 2023, sem animação nem decodificação progressiva	CoreWebVitals.io
Brave Beta 1.98+	Com suporte, baseado no Chromium 155	jpegxl.info

Quanto menores ficam os arquivos

Os números sobre o tamanho variam. O CoreWebVitals.io diz que os arquivos JPEG XL são 50-60% menores que o JPEG e 10-15% menores que o AVIF. Tanto essa fonte quanto o Fileza colocam a recompressão JPEG sem perdas em cerca de 20% menor.

Nem todos concordam com essas comparações. Uma crítica detalhada em setembro argumentou que o AVIF agora supera o JPEG XL em compressão. Meça com as suas próprias imagens antes de escolher um vencedor.

O que isso significa para os desenvolvedores

• Sirva JPEG XL com uma alternativa. Use o elemento HTML picture com uma fonte do tipo image/jxl, ou verifique o cabeçalho Accept no servidor. O Chrome anterior à versão 155 e outros navegadores sem suporte ainda precisam de JPEG, WebP ou AVIF.
• Comece pela recompressão JPEG sem perdas. É o ganho mais seguro. Os JPEGs existentes encolhem cerca de 20% e podem ser devolvidos ao original exato, então nada se perde se você mudar de ideia.
• Teste animação e imagens progressivas no Safari. O CoreWebVitals.io diz que o Safari não tem nenhum dos dois. Um JXL progressivo que parece bom no Chrome pode carregar tudo de uma vez lá.
• Atualize seu pipeline de imagens. CDNs, redimensionadores e validadores de upload que rejeitam tipos MIME desconhecidos vão bloquear arquivos .jxl. Verifique-os antes que os usuários comecem a enviar arquivos.
• Acompanhe o Largest Contentful Paint. Imagens principais menores podem melhorar essa pontuação do Core Web Vitals, que mede quando o conteúdo principal aparece. Compare antes e depois com tráfego real, não só em um teste de laboratório.

Acompanhe o lançamento do Firefox 158 em 13 de outubro. Se ele sair no prazo, o JPEG XL passa a ser um formato com o qual você pode planejar, em vez de um experimento.