JPEG XL vs AVIF: Qual Formato Você Deve Utilizar em Produção?

Para entrega web em produção em 2026, utilize AVIF: ele possui aproximadamente 93% de cobertura global de navegadores em meados de 2026, além de suporte maduro em CDNs, CMSs e ferramentas de build. O JPEG XL é tecnicamente o formato superior — codificação mais rápida, compressão lossless decisivamente melhor, decodificação progressiva nativa — mas o Chrome ainda o disponibiliza apenas por meio de uma flag, deixando o JXL com cerca de 15% de cobertura, toda ela via Safari, que o caniuse classifica como suporte parcial. Esse único fato decide a questão para qualquer site público: enquanto o Chrome não habilitar o JXL por padrão, uma stack de entrega JXL-first servirá AVIF ou JPEG para a grande maioria dos seus usuários de qualquer forma.

Este artigo resolve diretamente o caso de decisão intermediária: você já serve WebP ou AVIF, conhece as limitações do JPEG e quer uma escolha defensável baseada na realidade atual dos navegadores, não em evangelismo de formatos. O texto analisa cada critério — compressão, suporte de navegadores, custo de codificação, renderização progressiva —, fornece um snippet correto de <picture> e indica o sinal específico a observar que inverte a recomendação.

O Que Cada Formato Realmente É

AVIF e JPEG XL resolvem o mesmo problema — imagens menores com qualidade igual ou superior — mas vêm de linhagens de design opostas. O AVIF (AV1 Image File Format) foi introduzido pela Alliance for Open Media em 2019 e deriva da codificação intra de keyframe do codec de vídeo AV1, utilizado por serviços como YouTube e Netflix. O JPEG XL (ISO/IEC 18181) foi desenvolvido especificamente como formato de imagem estática pelo Joint Photographic Experts Group em conjunto com o Google e a Cloudinary, finalizado como padrão em 2022.

Essa diferença de linhagem — AVIF derivado de um codec de vídeo, JPEG XL desenvolvido especificamente para imagens estáticas — explica a maior parte dos trade-offs a seguir. O AVIF herda a forte compressão lossy fotográfica do AV1 e seu encoder com alto consumo de CPU. O JPEG XL foi projetado em torno de preocupações específicas de imagem: decodificação progressiva, profundidade de cor em alta resolução, modos lossless e uma funcionalidade que nenhum outro formato moderno oferece — recompressão lossless de JPEG. Um JPEG existente pode ser transcodificado para JXL, reduzindo o tamanho do arquivo em aproximadamente 20%, e decodificado de volta ao JPEG original byte a byte. Isso torna o JXL o único formato viável para arquivar grandes bibliotecas de JPEG sem perda de qualidade — um critério de decisão genuíno, não uma nota de rodapé.

Compressão: Quem Vence Depende do Conteúdo

O AVIF vence na compressão lossy fotográfica em qualidade baixa a média; o JPEG XL vence em alta qualidade, em conteúdo não fotográfico ou gráfico plano, e decisivamente no modo lossless. Não existe uma resposta única do tipo “X é N% menor”, e qualquer artigo que forneça uma está superestimando um resultado que depende do conteúdo.

O panorama prático:

• Lossy fotográfico, qualidade média: A perda do AVIF é mais suave e natural em bitrates agressivos — ele suaviza bordas e oculta artefatos onde o modo VarDCT do JPEG XL pode produzir ringing ou blocking semelhantes ao JPEG legado. Este é o terreno natural do AVIF e o caso mais comum na web.
• Alta qualidade e conteúdo não fotográfico: O JPEG XL iguala ou supera o AVIF, especialmente em ilustrações, logotipos, capturas de tela e gráficos com muito texto, onde seu modo de codificação modular lida com regiões de cor plana de forma limpa.
• Lossless: O JPEG XL é decisivamente melhor. O AVIF lossless é impraticável — mal supera o PNG — enquanto o JXL lossless é competitivo com o PNG e frequentemente muito menor.

As taxas de compressão variam significativamente conforme o conteúdo da imagem e a configuração de qualidade; a vantagem do JXL sobre o AVIF em particular é dependente do conteúdo e não é um número estabelecido. Antes de comprometer uma biblioteca de conteúdo com um formato, teste seus assets específicos no Squoosh, que codifica ambos os formatos no navegador e mostra o trade-off de tamanho/qualidade para suas imagens, e não para o conjunto de benchmarks de outra pessoa.

Suporte de Navegadores: O Eixo Decisivo

O suporte de navegadores é onde essa decisão é efetivamente tomada, e é o eixo que a maioria dos artigos de referência erra ou reporta de forma desatualizada. Em meados de 2026, o AVIF tem cerca de 93% de cobertura global e está ativado por padrão no Chrome, Edge, Firefox e Safari. O JPEG XL está em torno de 15% de cobertura — toda ela via Safari, e classificada como parcial.

O histórico do Chrome importa porque dois dos três artigos mais citados o relatam incorretamente. A linha do tempo precisa:

A afirmação amplamente repetida de que o Chrome “descontinuou” o JPEG XL está agora desatualizada. O Chromium revogou a designação de obsoleto do formato e reintegrou a decodificação usando um novo decoder baseado em Rust em vez do libjxl em C++. Mas reintegração não é o mesmo que disponibilização: no canal estável atual, a decodificação JXL no Chrome permanece desabilitada por padrão e requer ativação manual via chrome://flags/#enable-jxl-image-format. O Firefox mantém o código JXL no Nightly por trás da preferência image.jxl.enabled, mas não o compila nas versões de lançamento e não publicou nenhum cronograma de disponibilização.

A tradução para uma decisão de entrega é a parte que todo artigo de referência implica, mas nenhum afirma claramente: um elemento <picture> com JXL-first hoje serve AVIF ou JPEG para cerca de 85% dos seus usuários. Você codifica e armazena três variantes de formato para entregar JXL a aproximadamente um em cada sete visitantes — e mesmo esse alcance é suporte parcial exclusivo do Safari. Esse é o custo real de adotar JXL-first agora, e ele só se justifica quando o Chrome habilitar o formato por padrão.

Custo de Codificação e Renderização Progressiva

O JPEG XL codifica mais rápido que o AVIF e suporta decodificação progressiva de forma única; a codificação AVIF é pesada em CPU e não possui modo progressivo verdadeiro. Ambas as diferenças são operacionalmente relevantes — uma no seu pipeline de build, outra no tempo de carregamento percebido pelos usuários.

A codificação AVIF é a etapa lenta na maioria dos pipelines

A codificação AVIF com o encoder de referência AV1 (libaom-av1) é a etapa mais lenta em um pipeline de imagens típico, materialmente mais lenta por imagem do que o JPEG XL em qualidade perceptual equivalente. Para uma única imagem hero convertida manualmente, isso é insignificante. Para um job de CI que processa centenas de imagens de produtos a cada deploy, é uma restrição real: o tempo de codificação escala com a quantidade de imagens e o encoder AV1 é computacionalmente caro por design.

Mitigações práticas para um pipeline Node.js:

• Use o Sharp, que encapsula o libvips, para codificação AVIF e JXL. Ele expõe controles de quality e effort que trocam tempo de codificação por tamanho de saída.
• Ajuste a configuração de effort/speed em vez de executar o encoder no esforço máximo por padrão — a codificação AVIF com alto esforço produz arquivos marginalmente menores a um grande custo de tempo.
• Paralelize entre worker threads ou núcleos de CPU, ou delegue a conversão a uma CDN que codifica on-the-fly para que nunca bloqueie seu build.

const sharp = require("sharp");

// AVIF: menor `effort` troca um pouco de tamanho por codificação CI muito mais rápida
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXL codifica mais rápido em qualidade comparável (requer um build com libjxl habilitado)
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

Verifique a disponibilidade de formatos no seu build instalado do sharp com sharp.format — o suporte a JXL depende do libvips/libjxl empacotado e não é garantido em todas as distribuições.

A decodificação progressiva afeta o LCP percebido

O JPEG XL suporta decodificação progressiva nativa: o navegador renderiza uma versão de baixa qualidade da imagem imediatamente e a aprimora conforme os dados chegam. O AVIF não possui modo progressivo verdadeiro, portanto uma imagem AVIF grande ou é pintada completamente ou não é pintada. Em conexões lentas, isso se manifesta como atraso visível no Largest Contentful Paint — o slot da imagem hero permanece em branco até que o arquivo completo chegue.

Essa é uma classe de problema que observamos diretamente em session replays: em páginas com muitas imagens, um slot de imagem hero permanece em branco durante toda a duração do download de uma imagem grande em uma conexão limitada, com o timestamp do LCP fixado no momento em que o arquivo completo finalmente é pintado. A decodificação progressiva no estilo JXL aborda exatamente essa falha — uma imagem de baixa qualidade aparecendo cedo e sendo aprimorada — que é o comportamento de performance perceptual que importa para usuários reais em redes lentas, e a razão pela qual o tamanho do payload e a renderização progressiva são alavancas de LCP, não preferências cosméticas.

O Framework de Decisão: Utilize X Se…

Utilize AVIF agora para produção na web pública, com fallbacks de WebP e JPEG via <picture>. Recorra ao JPEG XL em casos específicos e delimitados: workflows lossless ou de arquivamento, bibliotecas de imagens não fotográficas, audiências concentradas no Safari ou grandes arquivos JPEG que você deseja recomprimir sem perda de qualidade.

Utilize AVIF se:

• Você opera um site de produção público que precisa de ampla cobertura hoje.
• Seus assets são majoritariamente fotográficos ou mistos.
• Você usa um CMS ou CDN com suporte nativo — o AVIF é nativo no WordPress desde o WP 6.5 (abril de 2024), e as principais CDNs o codificam on-the-fly.
• Você quer ganhos mensuráveis de LCP em relação ao JPEG/WebP sem gerenciar uma quarta variante de formato.

Recorra ao JPEG XL se:

• Você mantém um grande arquivo JPEG e quer recompressão lossless — transcodifique para JXL (~20% menor) e reconstrua os originais byte a byte.
• Seu conteúdo é predominantemente não fotográfico: ilustrações, logotipos, diagramas, capturas de tela.
• Sua audiência é majoritariamente usuária de Safari e você controla todo o markup <picture> em uma configuração headless ou personalizada.
• Você está construindo uma entrega voltada para o futuro para o momento em que o Chrome habilitar o JXL por padrão.

O JPEG XL não possui suporte nativo de upload no WordPress em meados de 2026, o que reforça o AVIF como a escolha prática para CMS.

Um snippet correto e atual de <picture>

Em um elemento <picture>, o navegador avalia as entradas <source> na ordem do documento e seleciona o primeiro type que suporta, recorrendo ao <img> se nenhum corresponder. A ordem, portanto, não é cosmética — é o algoritmo de seleção. Liste os formatos do melhor ao pior conforme sua prioridade, e faça o fallback do <img> ser um JPEG com suporte universal, não WebP (o WebP precisa de sua própria entrada <source> porque é um tipo MIME distinto).

<picture>
  <!-- JXL primeiro: servido apenas para Safari 17+ (parcial); Chrome com flag desativada em meados de 2026 -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF: ~93% de cobertura, a camada principal para quase todo o tráfego -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: cobre Chrome/Firefox mais antigos que são anteriores ao AVIF -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: fallback incondicional; o src que sempre renderiza -->
  <img src="hero.jpg" alt="Descrição" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

A leitura honesta sobre essa stack de quatro camadas: hoje ela custa quatro variantes codificadas para entregar JXL a uma minoria exclusiva do Safari. Se sua audiência não é majoritariamente usuária de Safari e você não tem razão de arquivamento para o JXL, remova o primeiro <source> e utilize a versão de três camadas AVIF/WebP/JPEG — ela cobre quase todo o tráfego com um formato a menos para construir e armazenar. Adicione a source JXL quando, e não antes de, o Chrome ativar a flag.

O Que Observar Para a Recomendação Mudar

O gatilho prático para tornar o JPEG XL seu formato de entrega principal é o Chrome disponibilizar chrome://flags/#enable-jxl-image-format como ativado por padrão; até que isso aconteça, a matemática de cobertura — aproximadamente 15% JXL (parcial exclusivo do Safari) versus ~93% AVIF — mantém o AVIF como o único formato primário defensável para produção na web pública. Sinais concretos que valem a pena monitorar:

• A entrada do Chrome Platform Status para JPEG XL mudando de flagged para shipped/default-on.
• A cobertura de suporte completo do caniuse.com/jpegxl ultrapassando um limiar utilizável e perdendo sua designação parcial.
• O Firefox movendo o JXL do Nightly para um build de lançamento.
• As principais CDNs habilitando a conversão JXL por padrão em seus pipelines de imagem.

Quando o primeiro desses eventos ocorrer, uma stack <picture> com JXL-first deixa de ser um custo especulativo e se torna a recomendação padrão, e o framework acima se inverte.

Conclusão

Utilize AVIF hoje e mantenha seu markup <picture> pronto para o JPEG XL. O AVIF é o formato que alcança seus usuários agora, com as ferramentas e o suporte de CMS para respaldá-lo; o JPEG XL é o formato tecnicamente superior e a ferramenta certa para arquivos lossless e recompressão de JPEG, mas seu caso na web pública está inteiramente condicionado ao Chrome habilitá-lo por padrão. Converta seus assets para AVIF, adicione fallbacks de WebP e JPEG, e monitore a entrada no Chrome Platform Status — o dia em que essa flag for ativada por padrão é o dia para reconsiderar o JXL como sua source principal.

Perguntas Frequentes

Servir AVIF e uma source JXL no mesmo elemento picture dobra meu armazenamento e largura de banda?

Aumenta o armazenamento, mas não a largura de banda por requisição. Cada variante de formato que você lista adiciona um arquivo codificado para armazenar, portanto uma stack de quatro camadas JXL, AVIF, WebP, JPEG significa quatro arquivos armazenados por imagem. A largura de banda não é afetada porque o navegador baixa apenas a primeira source suportada que seleciona, nunca múltiplas variantes. O custo real de uma stack JXL-first é a codificação e o armazenamento extras para alcançar uma minoria exclusiva do Safari, não downloads duplicados.

Posso converter minhas imagens AVIF para JPEG XL posteriormente sem recodificar a partir do original?

Não, não sem perda de qualidade. A transcodificação lossless do JPEG XL é exclusiva para fontes JPEG, não AVIF ou WebP. Você pode encapsular um JPEG existente em JXL e reconstruí-lo byte a byte, mas AVIF e WebP são formatos lossy sem esse caminho reversível. Converter AVIF para JXL significa decodificar o AVIF já comprimido e recodificá-lo, acumulando artefatos. Sempre mantenha seus masters lossless originais para poder recodificar para qualquer formato de forma limpa.

Por que minha imagem hero em AVIF ainda prejudica o Largest Contentful Paint mesmo sendo menor que o JPEG?

O AVIF não possui decodificação progressiva verdadeira, portanto uma imagem AVIF grande só é pintada quando o arquivo completo chega, em vez de renderizar primeiro uma prévia de baixa qualidade. Em uma conexão lenta, o slot hero permanece em branco durante todo o download, e o timestamp do LCP fica fixado na pintura final. Um tamanho total de arquivo menor não muda esse comportamento de tudo ou nada. A decodificação progressiva do JPEG XL aprimora incrementalmente, o que melhora o carregamento percebido mesmo em contagens de bytes similares.

Um navegador que suporta tanto AVIF quanto JPEG XL escolherá qualquer source que eu listar primeiro?

Sim. O elemento picture seleciona a primeira source cujo atributo type o navegador suporta, avaliado na ordem do documento, independentemente do tamanho do arquivo ou da capacidade do formato. Se você listar JXL antes de AVIF, um build do Safari que suporta ambos servirá JXL; inverta a ordem e ele servirá AVIF. O navegador não compara qualidade nem peso, portanto a ordem das sources é o mecanismo de seleção. Coloque seu formato preferido primeiro e termine com um fallback img JPEG com suporte universal.