Escolhendo Formatos de Imagem para a Web em 2026: O Império do JPEG, a Ascensão do AVIF e o Exílio do JPEG XL

Pegue uma foto de 12 MP (4000 × 3000 pixels) e exporte de seis jeitos. PNG: 24 MB. JPEG na qualidade 90: 3,4 MB. WebP com qualidade visual equivalente: cerca de 2,4 MB. AVIF com qualidade visual equivalente: cerca de 1,7 MB. GIF, com dithering até o teto de 256 cores: 6 MB, com banding visível por toda parte. O SVG não está na lista: ele descreve desenhos, e uma fotografia não é um desenho.

Mesma imagem na tela, uma diferença de 14× no disco. Essa diferença é engenharia, não gosto. Cada formato é um conjunto de decisões tomadas sob as restrições de um ano específico, e essas decisões ainda aparecem no peso da sua página hoje.

Esta é a versão de decisão desse experimento: o que cada formato realmente faz com seus pixels, quais navegadores o decodificam em meados de 2026, o que a web está de fato servindo e, no fim, uma tabela que você pode colar na wiki do time.

Os concorrentes, um de cada vez

JPEG (1992). O mecanismo: dividir a imagem em blocos de 8 × 8, transformar cada bloco em frequências com a transformada discreta de cosseno e então quantizar os detalhes finos em direção a zero, segundo um modelo da visão humana. Pontos fortes: decodifica em todo dispositivo fabricado desde meados dos anos 90, codifica rápido e é excelente em fotos de tom contínuo. Fraquezas: sem transparência, sem animação, ringing visível em volta de bordas nítidas e de texto, e uma qualidade que só piora a cada novo salvamento. Serve para fotografias e para qualquer coisa que precise abrir em absolutamente todo lugar.

PNG (1996). O mecanismo: totalmente sem perda. Cada linha de varredura é filtrada com um preditor e depois empacotada com DEFLATE, a mesma dupla de LZ77 com Huffman que está dentro do gzip. Pontos fortes: saída exata, pixel a pixel, alfa completo, suporte universal. A fraqueza são as fotos: o ruído do sensor derrota o preditor, então uma foto de 12 MP comprime talvez 1,5:1 sobre os pixels brutos. Serve para capturas de tela, telas de interface, diagramas e qualquer coisa com texto ou cor chapada.

GIF (1987). O mecanismo: compressão LZW sobre uma paleta de no máximo 256 cores, com vários quadros empacotados num único arquivo. O único ponto forte que resta é a animação que funciona em todo lugar, inclusive em clientes de e-mail sem suporte a formatos modernos. As fraquezas são todo o resto: 256 cores, transparência de um bit e arquivos que fazem o vídeo equivalente parecer minúsculo. Serve para memes e loops pequenos de interface.

SVG (2001). O mecanismo: nenhum, no sentido raster. SVG é XML que descreve formas, caminhos e gradientes, e o renderizador desenha os pixels na resolução que a tela pedir. Pontos fortes: independência de resolução, tamanho minúsculo para arte geométrica, estilizável com CSS. Fraquezas: só funciona para conteúdo genuinamente vetorial, e um arquivo com milhares de nós e filtros pesados pode custar mais que um bitmap. Serve para logotipos, ícones, gráficos e diagramas.

WebP (2010). O mecanismo: o modo com perda toma emprestada a predição intraquadro do codec de vídeo VP8, e o modo sem perda usa predição espacial combinada com referências retroativas no estilo LZ77. Pontos fortes: os dois modos num único formato, alfa no modo com perda, animação e arquivos de 25 a 34% menores que JPEG com qualidade equivalente, no estudo da própria Google. Fraquezas: um limite rígido de 16383 × 16383 pixels e um codificador que gasta mais CPU que a libjpeg. Serve para quase tudo, e é por isso que virou o caminho padrão de upgrade para JPEG, PNG e GIF na web.

AVIF (2019). O mecanismo: quadros estáticos do codec de vídeo AV1, embalados no contêiner HEIF. Pontos fortes: a melhor compressão com perda que dá para entregar num navegador, cerca de 50% menor que JPEG com qualidade equivalente nos testes da Netflix em 2020, além de cor de 10 e 12 bits, HDR, alfa e animação. Fraquezas: a codificação é genuinamente lenta, não há renderização progressiva (a imagem aparece de uma vez ou não aparece) e configurações de qualidade muito baixas borram a textura de um jeito que a blocagem honesta do JPEG não borra. Serve para fotografias e imagens hero, onde o tamanho do arquivo mais importa.

HEIC (2015). O mecanismo: quadros estáticos HEVC, também num contêiner HEIF. Pontos fortes: compressão no nível do AV1 e formato de captura padrão em todo iPhone desde 2017. A fraqueza é jurídica, não técnica: o HEVC está preso a pools de patentes, e todos os fabricantes de navegador, exceto a Apple, se recusaram a pagar. Ele pertence ao rolo da câmera, não à web.

JPEG XL (2021). O mecanismo: dois motores sob o mesmo teto, VarDCT para o trabalho com perda e um modo modular para o sem perda, além de um truque que nenhum outro formato tem: recomprimir um JPEG existente sem perda para cerca de 80% do tamanho original, com pixels bit a bit idênticos. Pontos fortes: decodificação progressiva, excelentes taxas sem perda, fotografia de alta fidelidade. A fraqueza é a adoção, que é, em grande parte, uma história de política entre navegadores, contada mais abaixo. Serve para pipelines de fotografia e arquivamento — e, em dispositivos Apple, para a web.

Suporte nos navegadores, meados de 2026

Versões em que cada formato passou a vir ativado por padrão, segundo dados do caniuse:

Três detalhes dessa tabela valem uma nota. O AVIF no iOS tecnicamente chegou no Safari 16.0, mas sem animação; é no 16.4 que o suporte completo chega, tanto no macOS quanto no iOS. O Edge levou anos a mais que o Chrome para entregar AVIF, apesar de ser Chromium, porque a Microsoft manteve o decodificador desativado por mais tempo que a Google. E a linha do JPEG XL esconde uma história incomum, que ganha uma seção própria abaixo.

Cobertura global, segundo os números de 2026 do caniuse: o WebP gira em torno de 97%, o AVIF em torno de 93 a 94%. JPEG e PNG estão efetivamente em 100%, e isso dificilmente vai mudar.

A hierarquia de compatibilidade

Agrupados por alcance, os formatos se dividem em cinco níveis.

O primeiro nível é o conjunto universal: JPEG, PNG, GIF e SVG. Eles decodificam em todo navegador, todo cliente de e-mail, toda pré-visualização de sistema operacional e todo quiosque de dez anos atrás. Se um arquivo precisa abrir de qualquer jeito, ele sai num desses quatro.

O segundo nível é o WebP, sozinho. O último grande resistente era o Safari, e o Safari 14 fechou essa lacuna em setembro de 2020. O que sobra são instalações de Internet Explorer e WebViews antigas do Android. Para um site — ao contrário de um e-mail —, o WebP é um padrão seguro há cerca de cinco anos.

O terceiro nível é o AVIF. O Chrome o teve em 2020, o Firefox em 2021, o Safari em 2022 (suporte completo em março de 2023, com o 16.4) e o Edge o ativou por padrão em janeiro de 2024. Desde o início de 2024, todo motor importante decodifica AVIF de fábrica. Os poucos pontos percentuais que faltam são iPhones antigos e frotas de Windows sem gestão, e é para isso que servem os fallbacks.

O quarto nível é o JPEG XL, travado. A Apple o entrega nativamente desde o Safari 17, em setembro de 2023. O Google removeu o decodificador experimental do Chromium no fim de 2022, em vigor a partir do Chrome 110 em fevereiro de 2023, e depois voltou atrás e integrou um decodificador em Rust (jxl-rs), que chegou no Chrome 145 em fevereiro de 2026, ainda atrás de uma flag. O Firefox tem um decodificador atrás de flag há anos. Ou seja, suporte a JPEG XL em meados de 2026 significa todos os usuários de Apple mais a fração ínfima de usuários de Chrome e Firefox que ativam flags — um grupo pequeno demais para servir de base.

O quinto nível é o HEIC: Safari 17 nas plataformas Apple, e nada mais em lugar nenhum. Isso é menos um nível do que um ecossistema de um único fornecedor.

O que a web realmente serve

Suporte não é uso. O Web Almanac do HTTP Archive rastreia milhões de páginas reais e conta o que elas servem, e a edição de 2024 (a mais recente com dados completos de mídia) se lê como uma geleira em movimento. O JPEG ainda era o formato mais comum, com 32% de todas as imagens, mas isso é oito pontos inteiros abaixo dos 40% de 2022. O WebP ficou com três desses pontos e chegou a 12%. O SVG ganhou cerca de dois. O AVIF alcançou algo em torno de 1%, o que soa como erro de arredondamento até você ler em termos relativos: quase 4× de crescimento em dois anos. O ICO manteve 1,3%, quase tudo dele favicons. E o GIF, com 37 anos de idade, de algum jeito ganhou um ponto.

Por que anda tão devagar? Três atritos fazem a maior parte do trabalho. Cache de CDN: as imagens ficam na borda indexadas por URL, e trocar de formato significa invalidar caches e recodificar bibliotecas inteiras. Dispositivos antigos: o gráfico de suporte diz 97%, mas os 3% que faltam se concentram em celulares Android baratos e frotas corporativas, e alguns sites não podem se dar ao luxo de perder uma única venda por causa de uma imagem quebrada. Inércia de ferramentas: o CMS gera miniaturas em JPEG porque sempre gerou, a ferramenta de design exporta PNG porque esse é o botão grande, e mudar o padrão significa mexer num pipeline de build que não tem dono.

Há também o custo de codificação. A vantagem de compressão do AVIF é paga em CPU na hora de codificar, e é por isso que as CDNs de imagem cobram por ela e que equipes atentas pré-geram AVIF no build ou no upload, em vez de fazer isso sob demanda.

Para onde isso está indo

O AVIF é a aposta mais segura para os próximos anos. Ele é livre de royalties por projeto (a Alliance for Open Media foi fundada em 2015 por Amazon, Cisco, Google, Intel, Microsoft, Mozilla e Netflix explicitamente para escapar de pools de patentes no estilo HEVC), lida com perda e sem perda numa única especificação, carrega HDR e cruzou o limiar de suporte em que uma cadeia de fallback custa quase nada. Os custos reais são o tempo de codificação e a falta de decodificação progressiva. A pré-geração resolve o primeiro; o segundo é uma troca justa.

O JPEG XL merecia um destino melhor do que o que teve. Em mérito técnico, é o formato mais completo já padronizado: decodificação progressiva, o melhor modo sem perda, fotografia de alta profundidade de bits e recompressão sem perda de todo o acervo de JPEG existente. O Google o tirou do Chromium alegando interesse insuficiente do ecossistema, e o pedido de restauração virou uma das issues mais estreladas da história do tracker do Chromium. Três anos depois, o Google reverteu a decisão — mas, a essa altura, a janela de adoção já havia se fechado em grande parte. Enquanto o JPEG XL estava no exílio, o AVIF ficou com as integrações de CDN, os plugins de CMS e as caixas marcadas por padrão. O JPEG XL vai viver como o favorito dos arquivistas e como cidadão de primeira classe nos dispositivos Apple. Tinha os argumentos técnicos para a adoção em massa e, mesmo assim, ficou de fora.

O HEIC não vai virar um formato de web. A razão não tem nada a ver com qualidade. A decodificação HEVC exige licenças de patente que os fabricantes de navegadores gratuitos se recusam a pagar há uma década, e a web roda em tecnologia livre de royalties. Um formato que três dos quatro grandes motores não decodificam não é um formato de web; é um problema de exportação que você resolve na fronteira.

A técnica de transição, por sua vez, está bem estabelecida e assume duas formas. Negociação de conteúdo no servidor: o navegador envia um cabeçalho Accept listando o que consegue decodificar, e o servidor ou a CDN escolhe a melhor variante para a mesma URL. No cliente: o elemento <picture>, que lista os candidatos e deixa o navegador ficar com o primeiro que ele entende:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

O <img> no final é o fallback universal, então nada quebra em lugar nenhum. É assim que você serve AVIF para os 93% e JPEG para o resto sem manter dois sites.

A tabela de decisão

Uma breve nota sobre favicons, porque a linha da tabela deixa alguns detalhes de fora. Navegadores modernos aceitam favicons em PNG e até em SVG, mas o ICO continua sendo o único formato que todo crawler, leitor de RSS e aba de navegador bem antiga entende, e um arquivo ICO pode embalar vários tamanhos num único contêiner. Se o seu logotipo vive hoje em outro formato, JPG para ICO, WebP para ICO e PNG para ICO geram um ICO com vários tamanhos direto no seu navegador.

Convertendo entre formatos

A maioria das tarefas de conversão decorre das seções acima. A mais comum, de longe, é tirar um HEIC do iPhone e colocá-lo em algo que o resto do mundo consiga abrir. HEIC para JPG é a jogada certa para compartilhar, já que o HEIC já é com perda e o JPEG evita que o dano se acumule. HEIC para PNG congela o estado atual para edição, e HEIC para WebP faz sentido quando o destino é um site.

Depois vem o triângulo JPEG, PNG, WebP. Levando um JPEG para um fluxo de design: JPG para PNG, não porque ganha qualidade (não ganha), mas porque para de perder. Encolhendo para a web: JPG para WebP. No caminho contrário, para software mais antigo: WebP para JPG e WebP para PNG. Uma captura de tela em PNG indo para uma galeria de fotos: PNG para JPG, ou PNG para WebP quando você quer arquivos menores mantendo a transparência. Se você herdar digitalizações BMP descomprimidas, BMP para JPG, BMP para PNG e BMP para WebP são todos melhores que ficar mandando relíquias de vários megabytes por e-mail. Até documentos esbarram na mesma bifurcação: PDF para JPG para páginas fotográficas, PDF para PNG quando o texto precisa continuar nítido e PDF para WebP quando a página vai para a web.

Todos esses conversores rodam a conversão localmente, no seu navegador, então o arquivo nunca sai do seu dispositivo.

Os formatos mudam. A regra, não: adapte o codec ao conteúdo e converta quando o conteúdo muda de função.