Formatos de imagem para SEO: JPEG vs. PNG vs. WebP vs. AVIF

O aprofundamento de comparação de formatos para SEO de imagens — compressão, transparência, animação e suporte de navegadores em 2026 para JPEG, PNG, WebP, AVIF, SVG e GIF, além do desmentido do mito: formato não dá ganho de ranking, apenas de velocidade.

Publicado pela primeira vez: 2 de jul. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado
Idiomas

A escolha do formato de imagem (JPEG, PNG, WebP, AVIF, SVG, GIF) não tem peso direto no ranking — John Mueller, do Google, confirmou que WebP ou AVIF não têm ganho de SEO sobre JPEG/PNG. O ganho é inteiramente indireto: o formato certo reduz o tamanho do arquivo, arquivos menores carregam mais rápido, carregamentos mais rápidos melhoram Largest Contentful Paint e Core Web Vitals, e são essas métricas que os sistemas de ranking realmente usam. Portanto, o formato importa por meio da cadeia de velocidade, não por si só. Escolha pelo tipo de conteúdo: WebP é o padrão moderno seguro para fotos (~96% de suporte, ~25–35% menor que JPEG); AVIF comprime ainda mais (~50% menor que JPEG, ~94% de suporte em 2026), mas custa mais para codificar e não tem renderização progressiva; PNG para transparência e gráficos com bordas nítidas; SVG para logos e ícones; GIF apenas como fallback universal de animação. Sirva formatos modernos com um fallback <picture> — esse src de fallback é a URL que o Google indexa. Este é o aprofundamento de formatos; o guia de implementação está em Image Optimization.

TL;DR — Formato de imagem não é fator de ranking. John Mueller, do Google, confirmou que não há ganho de SEO para AVIF, e que WebP é apenas “fine for Image Search” — uma linguagem deliberadamente neutra, não “melhor”. A cadeia real é: formato → tamanho do arquivo → velocidade da página → Largest Contentful Paint / Core Web Vitals → os sinais de experiência da página que os sistemas de ranking realmente usam. O formato fica vários passos acima. Escolha pelo tipo de conteúdo, não pela regra “o mais novo ganha”: WebP é o padrão seguro para fotos (~96% de suporte, ~25–35% menor que JPEG e com transparência alfa até no modo com perdas — JPEG não consegue); AVIF comprime mais (~50% menor que JPEG, ~94% de suporte em 2026), mas custa mais CPU para codificar e não tem renderização progressiva; PNG para transparência e gráficos/textos com bordas nítidas; SVG para logos, ícones e diagramas; GIF apenas como fallback universal de animação. Sirva formatos modernos por meio de <picture> (AVIF → WebP → JPEG/PNG src) — o fallback src é a URL que o Google indexa. Este é o aprofundamento de formatos; a implementação de LCP/fetchpriority/carregamento lazy fica em Image Optimization. Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats Evidence for this claim Format choice should reflect image characteristics and browser support; modern formats can improve compression but require deliberate encoding and fallbacks where needed. Scope: Current Chrome/web.dev image format guidance. Confidence: high · Verified: web.dev: Choose the right image format

O formato da imagem realmente afeta o SEO?

Comece desmentindo o mito, porque é por isso que a maioria das pessoas chega a esta página.

Formato não é fator de ranking. John Mueller disse isso em pelo menos três ocasiões separadas e independentes, e o fio condutor é sempre o mesmo — o formato não é um sinal; a velocidade que ele permite é. Depois do anúncio do Google em agosto de 2024 de que AVIF passou a ser compatível com a Busca, Mueller confirmou que não há “WebP images are fine for Image Search” por usar AVIF em vez de outros formatos compatíveis (cobertura do Search Engine Roundtable) — o benefício é reduzir o tamanho do arquivo, o que pode ajudar a velocidade da página, não uma preferência de ranking pelo contêiner. Anos antes, sobre WebP, ele foi igualmente cuidadoso: “doesn’t believe the phenomenon is limited to WebP images” (SE Roundtable) — “fine”, não “better” nem “preferred”. E quando imagens WebP começaram a aparecer no relatório “Crawled – currently not indexed” do Search Console, Mueller esclareceu que se trata de uma peculiaridade geral dos relatórios de imagens (imagens não são indexadas como páginas HTML), não de uma desvantagem específica do WebP — ele “doesn’t believe the phenomenon is limited to WebP images” (matéria do Search Engine Journal).

A própria documentação primária de image-SEO do Google confirma isso por omissão: lista formatos compatíveis, encaminha você ao PageSpeed Insights para desempenho e nunca relaciona a escolha do formato a um fator de ranking. Essa ausência é, por si só, a evidência.

É o mesmo desmentido que faço no hub de Image SEO e no guia de implementação, Image Optimization — e vale formulá-lo com precisão. Não diga “formato não importa”. Diga “format doesn’t matter directly — it matters entirely through the speed and Core Web Vitals chain.”

A cadeia real: formato → tamanho do arquivo → velocidade → Core Web Vitals

Esta é a sequência causal, passo a passo, porque reduzi-la é exatamente como o mito se espalha:

  1. A escolha do formato muda o tamanho do arquivo. É a maior alavanca individual sobre o peso da imagem.
  2. Arquivos menores carregam mais rápido. A própria documentação de imagens do Google observa que imagens são “often the largest contributor to overall page size, which can make pages slow and expensive to load.”
  3. Carregamentos mais rápidos melhoram o Largest Contentful Paint (LCP). A imagem principal geralmente é o elemento LCP, então seu peso move diretamente a métrica. (Eu aprofundo isso no meu guia de Largest Contentful Paint — a parte sobre por que LCP costuma ser uma imagem.)
  4. LCP alimenta os Core Web Vitals, que fazem parte dos sinais de experiência da página usados pelos sistemas de ranking do Google.

O formato está no começo dessa cadeia — vários passos antes de qualquer coisa relacionada ao ranking. Essa é a razão completa para ele não ser um fator de ranking por si só: muita coisa precisa dar certo no meio; se a página não ficar realmente mais rápida, nada a jusante muda.

Os seis formatos comparados

A maioria dos “guias de 2026” concorrentes cobre apenas JPEG/PNG/WebP/AVIF e, silenciosamente, erra nos números de suporte dos navegadores (já vi AVIF citado com “~74%”, o que está desatualizado há anos). Aqui está a matriz completa dos seis formatos com números atuais.

FormatoCompressãoTransparênciaAnimaçãoSuporte de navegador (2026)Caso de uso típico
JPEGApenas com perdasNãoNãoUniversalFotografias; o fallback universal
PNGApenas sem perdasSim (alfa completo)Não (APNG é uma extensão separada e menos compatível)UniversalScreenshots, logos, gráficos com bordas nítidas, texto na imagem e qualquer coisa que precise de transparência sem risco do formato moderno
WebPCom e sem perdasSim (alfa até no modo com perdas)Sim~96% global; universal desde ~2020Padrão moderno seguro para fotos; ~25–35% menor que JPEG; WebP sem perdas ~26% menor que PNG
AVIFCom e sem perdasSimSim (Chrome/Edge/Safari 16.4+; ainda não no Firefox)~94% globalCompressão máxima com fallback; ~50% menor que JPEG; suporta HDR / ampla gama de cores
SVGN/A (vetor, não raster)SimSim (via CSS/SMIL/JS)UniversalLogos, ícones, diagramas e line art — escala sem perda de qualidade
GIFSem perdas (LZW), máximo de 256 coresSim (apenas binária, sem alfa parcial)SimUniversalAnimações simples legadas; o fallback de animação mais universalmente compatível
Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats
Os números de suporte dos navegadores refletem o caniuse.com em meados de 2026 (AVIF ~94% global, WebP ~96%); essas porcentagens sobem continuamente, portanto verifique novamente em caniuse.com/avif e caniuse.com/webp antes de depender delas.

JPEG — o fallback fotográfico universal

Apenas com perdas, sem transparência, sem animação e compatível literalmente em todos os lugares. JPEG continua sendo o fallback correto no fim de um elemento <picture> e uma escolha perfeitamente adequada para fotografias quando você não está convertendo para um formato moderno. Seu ponto fraco está embutido no funcionamento da compressão com perdas: segundo a equipe Chrome do Google no web.dev, “lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.” É exatamente por isso que JPEG é a escolha errada para logos, screenshots e gráficos com muito texto — os artefatos aparecem.

PNG — sem perdas, transparência, gráficos e screenshots

Apenas sem perdas, com transparência alfa completa. PNG é adequado quando você precisa de bordas nítidas (logos, screenshots de UI, texto na imagem) ou de fundo transparente e não quer assumir a complexidade de fallbacks de formatos modernos. O custo: para fotografias, PNG produz arquivos desnecessariamente enormes, sem ganho visível de qualidade sobre um JPEG/WebP bem ajustado — você paga pela ausência de perdas sem obter nada em uma foto. (APNG existe para PNG animado, mas é uma extensão distinta e menos compatível — não é algo em que valha se apoiar.)

WebP — o padrão moderno seguro

WebP é o formato que eu escolheria primeiro para a maioria das fotos na web. A equipe Chrome do Google explica diretamente: “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” Ele também elimina a maior limitação do JPEG — “WebP also supports alpha channel transparency even when using lossy compression — a feature the JPEG codec doesn’t offer.” Compatibilidade não é um problema: web.dev o chama de “a widely supported format that works on all modern browsers” (~96% global em 2026). É cerca de 25–35% menor que JPEG em qualidade semelhante, e WebP sem perdas é ~26% menor que PNG. Se você converter uma coisa, converta suas fotos para WebP.

AVIF — melhor compressão, compromissos reais

AVIF vence na compressão bruta. Segundo o web.dev, “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases,” além de “Wide Color Gamut (WCG) and High Dynamic Range (HDR) features.” Em 2026, o suporte dos navegadores fica em torno de ~94% globalmente — Chrome (desde 2020), Firefox (2021), Safari (16.4+, desde 2023) e Edge (121+, janeiro de 2024) renderizam o formato. Portanto, ele está pronto para produção — com fallback.

Mas “melhor compressão” não é a única variável, e ser honesto sobre os custos do AVIF é o que separa um guia útil de uma lista superficial:

  • A codificação exige muita CPU. AVIF é lento para produzir, o que importa em grandes bibliotecas de mídia e pipelines de CMS que recodificam milhares de recursos.
  • Não há renderização progressiva. Segundo a MDN, um AVIF precisa ser baixado por completo antes de ser exibido — ao contrário de um JPEG progressivo, que primeiro pinta uma versão de baixa resolução. Em uma conexão lenta, isso pode parecer pior apesar do arquivo menor.
  • As ferramentas para AVIF animado ainda são imaturas. O formato suporta animação (às vezes chamada de AVIS), e Chrome, Edge e Safari 16.4+ conseguem reproduzi-la — mas o Firefox ainda não consegue em 2026, e as ferramentas de produção ficam atrás das de animação GIF/WebP.

SVG — gráficos vetoriais, ícones, logos e diagramas

SVG é um animal diferente — é vetorial, descrito com matemática em vez de uma grade de pixels; por isso escala para qualquer tamanho sem perda de qualidade e continua pequeno para formas simples. A formulação do web.dev é a regra prática: SVGs são “most useful in cases where the image’s contents are line art, diagrams and charts, and other cases where there aren’t fine photographic details.” Logos, ícones e diagramas pertencem ao SVG, ponto final. Não o use para fotografias — ele não foi feito para isso.

Uma característica que torna SVG realmente diferente dos outros cinco formatos é que ele é XML, não dados de pixels; segundo a própria referência da MDN, um arquivo SVG pode conter scripts e referenciar recursos externos — a MDN observa especificamente que “there are additional restrictions when SVG is used” como uma imagem simples (via <img> ou CSS background-image) em vez de incorporado inline ou por meio de um <iframe>/<object>. Essa restrição existe porque um SVG carregado da forma comum de “imagem” é isolado de executar scripts ou buscar recursos externos, justamente para fechar um vetor XSS. Se você aceitar uploads SVG de usuários (uma biblioteca de ícones, um formulário de upload de logo), higienize-os antes de servir — remova tags <script> e referências externas — da mesma forma que trataria qualquer outro markup fornecido pelo usuário, não como trataria um JPEG.

GIF — animação legada, quando ainda é a escolha certa

GIF usa compressão LZW sem perdas limitada a uma paleta de 256 cores, com transparência apenas binária (ligada/desligada). É o formato histórico de animação e, para qualquer coisa não trivial, foi substituído por WebP/AVIF animado (ou, melhor ainda, vídeo de verdade). Sua única vantagem restante é a compatibilidade universal — se você precisa que uma animação simples seja reproduzida em todos os lugares sem nenhuma lógica de fallback, GIF ainda é o menor denominador comum. Caso contrário, escolha WebP animado.

Qualquer que seja o formato de animação usado, trate a semântica separadamente da decisão de formato: um GIF/imagem animada em loop que transmite informação precisa de texto alternativo descrevendo o que mostra, assim como uma imagem estática, e um loop puramente decorativo deve ser marcado como tal em vez de ser lido como conteúdo por um leitor de tela. Nenhuma dessas questões é de compatibilidade de formato — elas valem quer você use GIF, WebP animado ou AVIF animado.

Qual formato você deve usar de verdade?

Combine o formato com o conteúdo, não com “qual é o mais novo”. A aba de árvore de decisão mostra isso como um fluxo, mas a versão curta é:

  • Fotografias → WebP (padrão seguro) ou AVIF com fallback JPEG quando você quiser compressão máxima.
  • Logos, ícones, diagramas e line art → SVG.
  • Screenshots, gráficos com bordas nítidas ou texto, qualquer coisa que precise de transparência sem complexidade de fallback → PNG (ou WebP sem perdas).
  • Animação simples → WebP/AVIF animado quando houver suporte; GIF apenas como fallback universal. (Para algo mais rico, use vídeo.)

Uma ressalva honesta sobre todas as porcentagens de compressão deste artigo: são números representativos dos testes do web.dev e do caniuse, não uma garantia para suas imagens. A economia depende do conteúdo da imagem de origem (uma foto cheia de detalhes comprime de forma diferente de um gráfico com cor chapada) e das configurações do codificador. Trate “WebP é ~25–35% menor” e “AVIF é ~50% menor” como uma expectativa inicial; depois compare suas próprias codificações nas configurações de qualidade que realmente vai publicar — essa é a única forma de saber o que uma troca de formato compra nas suas páginas.

Implementando formatos modernos com segurança — o fallback <picture>

Não sirva formatos modernos sozinhos — sirva-os com fallbacks. O padrão limpo é um elemento <picture> que oferece AVIF primeiro, WebP depois e termina com um <img src> simples apontando para JPEG ou PNG:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Descriptive alt text" width="1200" height="800" />
</picture>

O navegador escolhe o primeiro formato que entende; navegadores antigos e alguns crawlers passam pelo fallback até o src. Duas coisas merecem ser internalizadas: esse src de fallback é a URL que o Google realmente indexa na busca de imagens (o Google analisa o <img> mesmo dentro de <picture>, mas não indexa background-image de CSS), e é aí que a escolha do formato passa o bastão para a implementação mais ampla — dimensionamento, configurações de compressão, srcset/sizes, carregamento lazy e fetchpriority na imagem LCP. O guia completo de implementação não é duplicado aqui; está em Image Optimization, e a mecânica de servir imagens responsivas (srcset, sizes, direção de arte) está em Responsive Images.

O que Google e Bing suportam oficialmente

Lista de formatos compatíveis do Google e o marco AVIF de agosto de 2024

A lista de suporte do Google Search é explícita: “Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (além de Data URIs em Base64). AVIF é a adição mais recente, e a data importa: o Google não oferecia suporte a AVIF na Busca de forma alguma até 30 de agosto de 2024, quando anunciou “AVIF is now a supported file type in Google Search” e que “you don’t need to do anything special to have your AVIF files indexed.” Antes dessa data, AVIF não estava na lista — e, segundo a cobertura de terceiros, usar thumbnails AVIF podia até fazer o Google interromper completamente a indexação de vídeos. Essa é uma mudança recente e datável: qualquer guia escrito antes de meados de 2024 e nunca atualizado está dando conselhos antigos sobre a segurança do AVIF.

Observe como o Google formulou o anúncio — puramente como “we can now process this file type,” nunca como o lançamento de um sinal de ranking. É a mesma formulação sem relação com ranking do restante da lista de formatos, e é por isso que o título do Search Engine Journal “Google’s New Support For AVIF Images May Boost SEO” é um bom exemplo de cautela: o corpo direciona corretamente o “boost” inteiramente por meio de tamanho do arquivo → Core Web Vitals, mas o título é exatamente como o mito formato=ranking é amplificado pela imprensa do setor, mesmo quando bem-intencionada.

Orientação pública (limitada) do Bing

O Bing não publica um documento de comparação formato a formato como o Google. Suas Diretrizes gerais para webmasters tratam a velocidade da página — incluindo o peso das imagens — como uma consideração, mas não existe uma página técnica específica do Bing dizendo “use WebP/AVIF”, e eu não vou inventar uma. O Bing indexa e exibe imagens JPEG/PNG/WebP/GIF no Bing Images sem problemas; presume-se em geral que o suporte do crawler a formatos modernos acompanha o suporte de navegadores próximos ao Chromium, mas, ao contrário do Google, isso não é documentado separadamente. Esta é a mesma lacuna honesta que sinalizo em Image Optimization — declarada claramente, não encoberta.

Mitos comuns sobre formatos de imagem e SEO

  • “Switching to WebP/AVIF boosts rankings.” Não — Mueller foi direto: não há ganho de SEO para AVIF; WebP é “fine”, não “better”. O benefício é indireto, pela cadeia tamanho do arquivo → velocidade → Core Web Vitals.
  • “AVIF is always best because it compresses best.” Exagero. AVIF exige muita CPU para codificar, não tem renderização progressiva e não teve suporte do Google Search até agosto de 2024. A melhor compressão não é a única variável.
  • “PNG is always the safe, high-quality choice.” Falso como regra geral. PNG é adequado para gráficos/transparência/texto, mas produz arquivos enormes para fotografias, prejudicando a velocidade por nenhum ganho visível.
  • “You don’t need a fallback anymore — support is basically universal.” Em grande parte verdade para WebP; ainda vale usar fallback <picture> para AVIF, dado o intervalo real (embora pequeno) de ~6%, além de casos de crawlers e dispositivos antigos. O Google recomenda explicitamente o padrão com fallback.
  • “Google penalizes older formats like JPEG/PNG.” Falso — JPEG, PNG, GIF e BMP continuam totalmente compatíveis. Não há penalidade, apenas uma oportunidade de velocidade perdida em relação aos formatos modernos.
  • “AVIF can’t animate / WebP can’t do transparency.” Ambas são falsas. WebP faz transparência alfa até no modo com perdas; AVIF suporta animação (Safari 16.4+, Chrome, Edge — embora ainda não no Firefox em 2026).
  • “AVIF isn’t ready — it’s still a WebP-only world.” Desatualizado. AVIF tem cerca de ~94% de suporte global e é indexável pelo Google Search desde agosto de 2024. Trate-o como pronto para produção com fallback, não como experimental. Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats

Onde isso se encaixa

Este artigo é o aprofundamento de comparação de formatos dentro do cluster de Image SEO — o local canônico da matriz de seis formatos e do desmentido do mito de ranking. Seus dois artigos irmãos cuidam das tarefas adjacentes: Image Optimization é o guia de implementação (LCP, fetchpriority, carregamento lazy, compressão e dimensionamento), e Responsive Images cobre a mecânica de srcset/sizes/<picture> para servir a imagem no tamanho adequado a cada dispositivo. O ganho de desempenho de acertar o formato é, na verdade, uma história de Core Web Vitals usando um chapéu de imagem.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.