WebP vs AVIF vs JPEG: qual formato de imagem escolher em 2026?

TL;DR: AVIF é 20–30% menor que WebP e 30–50% menor que JPEG. WebP é cerca de 25–35% menor que JPEG. AVIF codifica 5–20× mais lento que WebP, enquanto WebP decodifica mais rápido que os três. O fluxo vencedor em 2026: sirva AVIF primeiro, com fallback para WebP, mantenha JPEG como rede de segurança universal e deixe o navegador escolher pelo elemento <picture>.

Essa resposta cobre a maioria dos leitores. A pergunta interessante é quando não recorrer a AVIF. Pule-o em orçamentos apertados de CI, onde o tempo de codificação importa mais que os bytes. Segure-o em uploads de usuários em tempo real, já que a codificação AVIF no navegador ainda é irregular. Mantenha JPEG como principal se você precisa suportar iOS 16.0–16.3 ou versões antigas do Edge no mundo real. Em todos os outros lugares, AVIF vence em tamanho de arquivo, desde que sua marcação <picture> esteja correta e seu CDN envie o MIME type certo.

O resto deste guia é o detalhe prático: números de suporte em 2026, um benchmark com foto real, uma árvore de decisão por caso de uso, padrões <picture> para copiar e colar, comandos de conversão e as quatro armadilhas que custam tempo às equipes. Se você só quer fazer a conversão, nosso compressor de imagens grátis lida com JPEG, PNG, WebP e AVIF no navegador, sem fazer upload de nada.

1. Suporte de navegadores em 2026: WebP a 97%, AVIF a 93%

Dois anos e meio depois de o Edge ter incluído AVIF, a diferença de suporte caiu para alguns pontos percentuais do tráfego global. A pergunta não é mais “tem suporte?” e sim “o que servimos para os últimos 3%?“

1.1 WebP: o padrão seguro

WebP chegou ao Chrome lá em 2012, ao Firefox 65 (2019), ao Edge 18 (2018) e ao Safari 14 (2020). Em maio de 2026, o caniuse coloca o suporte global em cerca de 97%. WebP saiu da categoria “alternativa moderna” e virou “fallback viável”. Se você for servir um único formato não-JPEG, é o WebP.

1.2 AVIF: agora utilizável como formato principal

AVIF chegou no Chrome 85 (agosto de 2020) e no Firefox 93 (outubro de 2021). O Safari 16.4 o habilitou no macOS e iOS em março de 2023. O Edge foi o atrasado, adicionando suporte de decodificação só na versão 121 (janeiro de 2024). A cobertura global em maio de 2026 está em cerca de 93–95%.

Uma quina que vale lembrar: iOS 16.0–16.3 tem um bug conhecido de decodificação AVIF que pode travar o Safari em certas imagens. Essas builds ainda estão vivas em dispositivos travados por MDM corporativo, então AVIF sem um fallback funcional de WebP ou JPEG é um risco real de indisponibilidade. Trate como “principal com seguro”, não “principal sozinho”.

1.3 Matriz rápida de compatibilidade

Formato	Suporte global (maio de 2026)	Limitação principal
JPEG	100%	Maiores arquivos; sem transparência; sem HDR
WebP	~97%	Sem HDR ou cor de 10 bits
AVIF	~93–95%	Codificação lenta; bug de decode no iOS 16.0–16.3; precisa de Edge 121+

2. Diferenças centrais: compressão, velocidade e recursos

2.1 Eficiência de compressão em uma foto real

Um benchmark a partir da mesma origem. Uma fotografia de paisagem 4000×3000, PNG original com cerca de 24 MB, recodificada em qualidade perceptualmente equivalente:

Codificação	Tamanho	Vs base JPEG
JPEG q75 (mozjpeg)	~2,1 MB	0% (base)
WebP q75 (libwebp)	~1,4 MB	33% menor
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	52% menor

AVIF q60 aqui é visualmente equivalente a JPEG q80 e WebP q75. Escalas de qualidade não são intercambiáveis entre codecs. Recodificar “JPEG q75 para AVIF q75” é o erro clássico de iniciante: você acaba com um AVIF inflado, idêntico à fonte.

2.2 Velocidade de codificação: o imposto de 5–20×

AVIF comprime mais porque trabalha mais. Usando libavif no padrão cpu-used 4, uma imagem 4000×3000 leva 5–20× mais que libwebp e cerca de 50× mais que mozjpeg. Esse custo se acumula em builds de CI, cold starts de Lambda e pipelines que recodificam milhares de assets.

Duas válvulas de escape. cavif --speed 9 (ou libavif cpu-used 9) chega a até 3× de libwebp ao custo de arquivos 5–8% maiores. E faça cache agressivo: um pipeline de assets endereçado por conteúdo, que pula a recodificação de fontes inalteradas, transforma um codec lento em um custo único.

2.3 Profundidade de cor e HDR

JPEG e WebP param em 8 bits sRGB. AVIF lida com cor de 10 e 12 bits, Rec. 2020, DCI-P3 e funções de transferência PQ/HLG nativamente. Para thumbnails de vídeo HDR, galerias profissionais de fotos ou provas de impressão pelo navegador, AVIF é hoje a única opção padronizada.

2.4 Transparência e animação

JPEG não tem nenhum dos dois. WebP e AVIF suportam alpha e animação. Para substituir PNG transparente, AVIF codifica alpha de forma mais compacta: uma ilustração de UI que encolhe 30–40% como WebP costuma encolher 50–70% como AVIF.

3. Árvore de decisão: qual formato para qual trabalho

3.1 Sites estáticos: blogs, páginas de marketing, docs

AVIF principal, WebP fallback, JPEG como rede de segurança. A codificação acontece uma vez no CI, então o imposto de 5–20× é pago em tempo de build, não em tempo do usuário. Esse é o caso canônico para o padrão <picture> de três fontes da seção 4.

3.2 Uploads de usuários: avatares, UGC, anexos de formulário

Comprima para WebP no navegador, recodifique para AVIF de forma assíncrona no servidor. O canvas.toBlob('image/avif') no navegador funciona apenas no Chrome 99+ hoje, então AVIF não pode ser o caminho de upload. WebP comprime rápido no navegador e economiza banda no próprio upload.

Para uma comparação mais profunda das bibliotecas client-side (Squoosh, browser-image-compression, Compressor.js) e como elas se combinam com Sharp ou Imagemin no servidor, veja o guia compressão de imagens: navegador vs Node.js irmão. Escolha de formato e local de processamento são ortogonais; este guia cobre o eixo do formato.

3.3 HDR e fotografia de alta fidelidade

Apenas AVIF. Nada mais na pilha aberta da web suporta cor de 10 ou 12 bits hoje. Pule o fallback para assets exclusivos de HDR, ou aceite que o fallback JPEG será SDR.

3.4 Públicos com muitos navegadores legados

JPEG principal, WebP opcional, sem AVIF. Portais governamentais, certos ambientes corporativos do Leste Asiático e ferramentas B2B com cauda longa de dispositivos às vezes mostram 5–10% de tráfego IE/Edge antigo no analytics. WebP já é seguro; AVIF ainda não.

3.5 Entrega via CDN em tempo real

libvips ou Sharp no servidor transmitindo WebP, com AVIF gerado em background worker e servido em cache hit. Não bloqueie a resposta na codificação AVIF. Cloudflare Polish, Vercel Image Optimization e Cloudinary f_auto automatizam o padrão.

4. O fallback `<picture>`, feito do jeito certo

O elemento <picture> existe exatamente para que o navegador possa escolher a melhor fonte suportada. Três camadas, listadas com AVIF primeiro, dão o orçamento ótimo de bytes sem quebrar em clientes mais antigos.

4.1 A base de três camadas

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Três coisas a observar. O navegador percorre os elementos <source> de cima para baixo e escolhe o primeiro cujo type ele entende; o resto é ignorado, não baixado. A tag <img> é o elemento realmente renderizado e herda atributos (alt, sizes, classes) independente de qual fonte vença. E width/height na <img> não são opcionais em 2026: eles reservam espaço e evitam Cumulative Layout Shift.

Para imagens acima da dobra, troque loading="lazy" por loading="eager" fetchpriority="high". Aplicar lazy-load na imagem LCP é uma das ciladas mais comuns de Core Web Vitals.

4.2 Responsivo mais formato: o padrão completo

Quando você também precisa de resoluções responsivas, repita srcset dentro de cada <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Sim, são nove arquivos gerados por imagem. Um passo de build é inegociável nessa escala; a seção 5.3 mostra o que plugar.

4.3 Negociação `Accept` no servidor como alternativa

Se seu CDN suportar, a negociação de conteúdo reduz a marcação a uma única tag <img>. O navegador envia Accept: image/avif,image/webp,image/apng,*/* e o CDN responde com o melhor formato suportado na mesma URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto e CloudFront com Lambda@Edge implementam isso. O trade-off: HTML menor e uma URL por imagem, mas lock-in de CDN e debug local mais difícil. Uma divisão útil é negociação no CDN para páginas de marketing, e <picture> explícito para UI de produto, onde comportamento determinístico importa.

5. Como converter imagens entre formatos

5.1 No navegador, sem upload

O caminho mais rápido para uma única conversão ou pequeno lote é só no navegador. Solte um JPEG no compressor de imagens grátis, escolha WebP ou AVIF como saída, e o arquivo nunca sai da sua máquina. Entrada AVIF é suportada em todo lugar; saída AVIF usa codificação nativa do navegador no Chrome 85+ e cai de forma transparente para WebP em navegadores que ainda não codificam AVIF.

5.2 Linha de comando para pipelines de build

Para um pipeline de produção, você quer saída determinística e builds reproduzíveis. Estes três comandos são reais:

# AVIF: cavif (Rust, instalação fácil via cargo ou brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (libwebp oficial do Google)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Os dois, mais resize, via libvips (mais rápido para lotes)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed vai de 0 (mais lento, menor) a 10 (mais rápido, maior). O padrão 4 é o ponto ideal para builds noturnos; suba para 9 em previews de PR onde velocidade vale mais que bytes.

5.3 Integração com pipeline de build

A maioria dos frameworks de site estático já encapsula esses encoders. Pegue o que combina com sua stack:

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programático — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Para assets minúsculos (ícones abaixo de uns 5 KB, avatares inline, cabeçalhos de e-mail), pule a rede totalmente e inclua inline como data URI usando codificação Base64. Isso troca uma requisição HTTP por alguns bytes extras de HTML, em geral uma vitória abaixo de ~5 KB.

Se você está escolhendo entre bibliotecas de compressão client-side e Node-side (Sharp vs Squoosh vs browser-image-compression), o guia compressão de imagens: navegador vs Node.js aprofunda em benchmarks e trade-offs.

6. Armadilhas e equívocos

6.1 “AVIF sempre vence” — não para screenshots e arte de linha

Os pontos fortes do AVIF são fotografias de tom contínuo. Em screenshots com texto nítido, capturas de UI e pixel art, WebP costuma produzir arquivos menores na mesma qualidade. O deblocking do AVIF pode introduzir banding sutil em regiões de cor chapada. Rode conversões nos dois sentidos e escolha o vencedor por classe de asset.

6.2 “WebP sem perdas substitui PNG transparente perfeitamente” — perto, não idêntico

WebP lossless é genuinamente menor que PNG, tipicamente cerca de 26%. O detalhe: “lossless” se aplica à imagem comprimida, mas o encoder pode mesmo assim alterar arredondamento do canal alpha em regiões de gradiente alto. Para reprodução pixel a pixel exata (imagens médicas, assets de arquivo, qualquer coisa legalmente exigida bater com a fonte), mantenha PNG. Para todo o resto, WebP lossless é vitória líquida.

6.3 “É só fazer upload de arquivos .avif” — seu CDN pode não saber o que são

Configurações antigas de nginx e Apache são anteriores ao AVIF. Se o /etc/nginx/mime.types não listar image/avif avif;, o nginx serve AVIF como application/octet-stream. O navegador vê o Content-Type errado, recusa renderizar a imagem e, silenciosamente, cai para JPEG, derrubando toda a otimização. Faça curl na URL do asset depois do deploy e cheque o header Content-Type. Cinco segundos de paranoia poupam uma semana de “por que o AVIF está quebrado em produção”.

6.4 O crash AVIF do iOS 16.0–16.3

Alguns arquivos AVIF disparam um crash de decodificação no Safari em iOS 16.0–16.3. O bug está corrigido na 16.4 (março de 2023), mas MDM corporativo e atualizações lentas de OEM mantêm dispositivos antigos vivos. Mitigação: nunca envie AVIF sem uma fonte WebP funcional no mesmo <picture>, e nunca defina um AVIF como src direto da <img>. Seguir os padrões da seção 4 já protege você.

7. O cheat sheet de 2026

Cenário	Principal	Fallback	Encoder
Páginas estáticas de marketing	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp no CI
Posts de blog e docs	WebP q75	JPEG q80	compressor de imagens grátis (manual) ou Sharp (build)
Uploads de usuários	WebP (no cliente)	JPEG (navegador sem encode WebP)	browser-image-compression + Sharp no servidor para AVIF
HDR / fotografia profissional	AVIF 10-bit q70	(nenhum — abandone fallback SDR ou pule AVIF totalmente)	cavif + libavif modo HEIF
Entrega CDN em tempo real	Negociado (AVIF ou WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Dois lembretes antes de subir. Sempre defina width e height na <img> para evitar CLS. Sempre verifique o header Content-Type de produção em pelo menos uma resposta AVIF: configuração de MIME quebrada mata AVIF em produção silenciosamente com mais frequência do que qualquer outra falha desta lista.

FAQ

Ainda preciso de fallback JPEG em 2026?

Sim. AVIF alcança cerca de 93% dos usuários globais e WebP cerca de 97%. Isso deixa uma população pequena, mas real (Edge antigo, Firefox abaixo de 93, iOS antes do 16.4, mais a zona do bug do iOS 16.0–16.3) que precisa de JPEG. Abandone JPEG só se seu analytics mostrar tráfego efetivamente zero desses navegadores e você puder provar.

Como mantenho builds de CI rápidos quando a codificação AVIF é lenta?

Três alavancas. Use cavif --speed 6 ou maior (padrão 4) para trocar ~5% de tamanho por ~3× de velocidade. Paralelize entre cores com GNU parallel ou o pool de workers do seu build tool. E faça cache por hash de conteúdo, para que imagens fonte inalteradas pulem o encoder totalmente. Combinadas, essas medidas costumam derrubar o tempo de build AVIF abaixo do antigo baseline single-thread do WebP.

A decodificação WebP é mesmo mais rápida que AVIF?

Sim. libwebp decodifica cerca de 2–3× mais rápido que libavif, e a diferença aumenta em mobile de baixo custo. Se seu gargalo de performance é decode (uma galeria longa de imagens em um Android básico, por exemplo) e não rede, WebP é o melhor formato principal. Para a maior parte do tráfego web, a economia de rede domina e AVIF ainda vence no geral.

Usuários de iPhone conseguem ver AVIF?

iPhones com iOS 16.4 (março de 2023) ou posterior suportam AVIF nativamente no Safari. Aparelhos em iOS 16.0–16.3 têm um bug documentado de decodificação que pode travar o Safari em certos arquivos AVIF; versões anteriores de iOS não suportam AVIF de forma alguma. Sempre envie um fallback WebP ou JPEG dentro de <picture> para que usuários afetados vejam algo.

Devo usar `<picture>` ou negociação por header Accept?

Projetos menores se beneficiam da marcação <picture> explícita: o comportamento é determinístico, você pode debugar localmente e adiciona talvez 80 bytes de HTML por imagem. Sites de alto tráfego ganham com negociação Accept no CDN: uma URL por imagem, upgrade automático de formato e o CDN faz cache de cada formato separadamente. Um híbrido comum é <picture> para UI de app e negociação por CDN para assets de marketing.

Por que meu PNG ficou maior depois de converter para WebP?

Quase sempre porque o PNG fonte já estava agressivamente otimizado por pngquant, oxipng ou ZopfliPNG, e o encoder do navegador, baseado em Canvas, não bate com essas ferramentas. Recodifique a partir do original (export do Photoshop, master da ferramenta de design, RAW) em vez de a partir do PNG otimizado. Se o PNG otimizado for sua única fonte, o original já está perto do ótimo, então deixe-o em paz.

AVIF suporta transparência?

Sim. AVIF suporta um canal alpha completo de 8 a 12 bits, e sua codificação de alpha geralmente é mais compacta que a do WebP. Uma ilustração PNG transparente convertida para AVIF tipicamente encolhe 50–70%, contra 30–40% como WebP. AVIF é o substituto mais forte para PNG transparente em qualquer contexto que não exija saída lossless pixel a pixel.

Navegadores conseguem codificar AVIF nativamente via toBlob(‘image/avif’)?

Apenas o Chrome 99+ no momento. Safari e Firefox conseguem decodificar AVIF, mas não conseguem codificar via APIs Canvas em maio de 2026. Para codificação AVIF no cliente você precisa hoje de bibliotecas WebAssembly como libavif-wasm ou jsquash, que adicionam 1–2 MB de payload. A maioria das stacks de produção comprime para WebP no navegador e delega a geração de AVIF a um worker no servidor.