Parece um detalhe pequeno — e é, literalmente. Mas o favicon carrega mais peso do que aparenta. Ele aparece na aba do navegador, nos favoritos, nos resultados de busca do Google, em atalhos de tela inicial e até em previews de links em algumas plataformas.
Escolher o formato errado pode significar um ícone borrado em telas de alta resolução, um arquivo pesado desnecessariamente ou um comportamento inconsistente entre navegadores. Neste post, analiso as diferenças reais entre SVG e PNG para favicon e explico quando cada um faz sentido.
Favicon é a abreviação de favorite icon. É aquele ícone pequeno exibido na aba do navegador ao lado do título da página. Originalmente introduzido pelo Internet Explorer em 1999 no formato .ico, o favicon evoluiu bastante: hoje suporta múltiplos formatos e tamanhos, e seu uso se expandiu para além da simples aba do navegador.
Na prática, o favicon pode aparecer em pelo menos seis contextos distintos:
aba do navegador;
barra de favoritos;
histórico de navegação;
atalhos na tela inicial de dispositivos móveis;
resultados do Google Search (nos chamados sitelinks);
previews em aplicativos de mensagens ou ferramentas de produtividade.
Cada contexto tem requisitos ligeiramente diferentes de tamanho e qualidade, o que torna a escolha do formato mais estratégica do que parece.
Favicon em PNG
O PNG é, historicamente, o formato mais utilizado para favicons modernos — e por boas razões. Mas também traz limitações que vale conhecer antes de adotá-lo como padrão.
Vantagens
A principal vantagem do PNG é a compatibilidade universal. Todos os navegadores modernos e a maioria dos legados reconhecem o formato sem qualquer fricção. Não há necessidade de fallback ou de lógica condicional no HTML — um único arquivo favicon-32x32.png já funciona na quase totalidade dos cenários de uso.
Além disso, o PNG suporta transparência com canal alfa, o que permite criar ícones com bordas suaves sobre qualquer cor de fundo. Isso é especialmente importante quando o favicon aparece sobre fundos variados — como na barra de favoritos, que pode ter tema claro ou escuro dependendo do sistema operacional do usuário.
Por fim, a cadeia de ferramentas para gerar PNGs é madura e acessível. Figma, Adobe Illustrator, GIMP e dezenas de geradores online exportam PNGs com qualidade controlável e tamanho previsível. A curva de aprendizado é praticamente zero.
Limitações
O ponto fraco do PNG é estrutural: trata-se de um formato rasterizado. Isso significa que o arquivo armazena pixels, não vetores.
Na prática, um favicon PNG desenhado para 32×32 pixels parecerá borrado ou pixelado em telas com alta densidade de pixels (Retina, por exemplo), a menos que versões maiores — como 64×64 ou 180×180 — sejam fornecidas separadamente.
Essa necessidade de múltiplos tamanhos é, por si só, uma limitação relevante. Para cobrir bem os diferentes contextos de exibição, é comum precisar de ao menos três ou quatro variações do mesmo ícone: 16×16, 32×32, 180×180 (para Apple Touch Icon) e eventualmente 192×192 ou 512×512 para manifests de PWA.
Isso aumenta o número de arquivos a gerenciar e o volume de requisições HTTP, mesmo que individualmente cada arquivo seja leve.
Outro ponto de atenção: o PNG não se adapta automaticamente ao tema do sistema operacional. Se o usuário usa modo escuro, um favicon com fundo escuro pode simplesmente desaparecer sobre a barra de abas. Contornar isso exige criar variantes manuais ou recorrer a outros formatos.
Favicon em SVG
O SVG como favicon ainda é relativamente novo — o suporte começou a se consolidar a partir de 2020 —, mas representa uma evolução significativa em termos de flexibilidade e manutenção.
Vantagens
A vantagem mais óbvia do SVG é a escalabilidade perfeita. Por ser um formato vetorial baseado em XML, o ícone é renderizado pelo navegador em qualquer resolução sem perda de qualidade.
Um único arquivo SVG exibe-se com nitidez em uma tela Full HD convencional e em um monitor 5K Retina sem qualquer diferença perceptível. Isso elimina a necessidade de gerar e manter múltiplas versões do mesmo ícone.
O SVG também suporta a media query prefers-color-scheme diretamente no código do arquivo. Isso significa que é possível definir, dentro do próprio SVG, versões distintas do ícone para modo claro e escuro — sem JavaScript, sem lógica adicional no servidor, sem arquivos separados. O exemplo abaixo ilustra como isso funciona na prática:
Outro benefício é o tamanho reduzido do arquivo. Para ícones simples baseados em formas geométricas ou tipografia, um SVG otimizado frequentemente pesa menos de 1 KB — muito abaixo de um PNG equivalente com transparência.
Isso tem impacto direto na performance, especialmente em conexões lentas ou dispositivos com largura de banda limitada.
Por ser um arquivo de texto, o SVG também é versionável com facilidade no Git, auditável e editável diretamente em qualquer editor de código — sem depender de software de design para pequenos ajustes.
Limitações
A limitação mais crítica do SVG para favicon é a compatibilidade. O Safari, por exemplo, só passou a suportar SVG como favicon a partir da versão 12 — e mesmo assim com algumas inconsistências. O Internet Explorer não suporta de forma alguma, o que pode ser relevante dependendo do perfil do público.
O SVG como favicon não funciona em todos os contextos. Ele é ignorado em bookmarks exportados para outros dispositivos, em algumas integrações de PWA, e em ferramentas que leem o favicon via scraping (como Slack, Notion e afins) — que tendem a priorizar PNG ou ICO. Se a presença consistente do ícone nesses cenários for importante, o SVG sozinho não é suficiente.
Ícones muito complexos — com gradientes, filtros ou efeitos avançados — também podem apresentar renderização inconsistente entre navegadores. O suporte a SVG para favicon é mais recente e menos robusto do que o suporte a SVG em imagens comuns dentro do HTML, então algumas funcionalidades avançadas podem não se comportar como esperado.
Compatibilidade com navegadores
Antes de tomar qualquer decisão, é importante ter clareza sobre o estado atual do suporte. A tabela abaixo resume a compatibilidade dos principais formatos de favicon nos navegadores mais usados:
Navegador
ICO
PNG
SVG
Chrome 80+
✅
✅
✅
Firefox 83+
✅
✅
✅
Safari 12+
✅
✅
⚠️ Parcial
Edge (Chromium)
✅
✅
✅
Internet Explorer
✅
⚠️ Parcial
❌
Opera 67+
✅
✅
✅
O suporte a SVG para favicon cresceu consideravelmente nos últimos anos. Para a maioria dos projetos com público em navegadores modernos, a cobertura já é bastante aceitável.
O problema surge quando há necessidade de suporte a versões mais antigas ou quando o favicon precisa funcionar em contextos além do navegador — como integrações com ferramentas externas, atalhos de PWA em Android/iOS ou scrapers de metadados.
O Safari em macOS ainda exibe o favicon PNG quando o SVG não é renderizado corretamente. Por isso, a estratégia de fornecer ambos os formatos no HTML — com SVG como preferencial e PNG como fallback — costuma ser a abordagem mais segura para projetos com alcance amplo.
Qual formato escolher na prática
A resposta direta é: depende do projeto. Mas há uma lógica clara para guiar a decisão.
Se o projeto precisa de simplicidade máxima, tem público potencialmente diversificado em termos de navegadores e não exige suporte a modo escuro, o PNG é a escolha mais segura. Um arquivo favicon-32x32.png e um apple-touch-icon.png de 180×180 já cobrem a esmagadora maioria dos casos com zero surpresas de compatibilidade.
Se o projeto é voltado para um público técnico ou moderno, prioriza performance, trabalha com identidade visual que precisa se adaptar ao modo escuro, ou simplesmente busca a melhor solução a longo prazo, o SVG é o caminho mais inteligente — desde que acompanhado de um fallback em PNG. A combinação dos dois formatos no HTML garante a melhor experiência possível sem abrir mão de compatibilidade.
Há ainda um terceiro cenário relevante: projetos que precisam suportar dispositivos móveis como um PWA. Nesse caso, o manifest.json entra em cena e requer ícones PNG em tamanhos específicos (geralmente 192×192 e 512×512). O SVG não é suportado como ícone de PWA na maioria dos contextos — o que reforça a necessidade de manter os PNGs mesmo em projetos que adotam SVG como favicon principal.
Para projetos novos, a abordagem mais equilibrada é declarar o SVG como favicon preferencial e incluir um PNG como fallback. Isso garante nitidez em telas de alta resolução, suporte a modo escuro sem custo adicional e compatibilidade retroativa com navegadores mais antigos — tudo com apenas dois arquivos.
Exemplo de implementação no HTML
A implementação correta no <head> do HTML faz toda a diferença. O navegador lê as declarações de favicon em ordem e utiliza o primeiro formato que consegue interpretar — então a ordem importa.
O trecho abaixo representa uma configuração completa e moderna, cobrindo os principais contextos de uso:
Alguns pontos importantes sobre essa estrutura: o SVG é declarado primeiro, com o tipo MIME correto (image/svg+xml), para que navegadores compatíveis o priorizem. Os PNGs vêm logo após como fallback natural. O Apple Touch Icon é separado porque iOS tem seu próprio mecanismo de ícones — ele não lê o favicon convencional para atalhos de tela inicial. E o manifest é necessário para qualquer projeto que funcione como PWA ou que queira controlar melhor a aparência do atalho em Android.
O arquivo SVG de favicon deve ser otimizado com ferramentas como SVGO antes de ir para produção. Muitos editores de design exportam SVGs com metadados desnecessários, definições de fontes embutidas e outros elementos que inflam o arquivo sem qualquer benefício visual.
Conclusão
O favicon é um daqueles elementos que raramente recebe atenção proporcional ao seu impacto. Ele aparece em múltiplos contextos, precisa funcionar bem em resoluções variadas e, idealmente, deveria se adaptar ao tema visual do sistema do usuário.
PNG resolve o problema com confiabilidade e simplicidade; SVG resolve com elegância e eficiência, mas ainda carrega limitações de compatibilidade que exigem uma estratégia complementar.
Na prática, a melhor abordagem para a maioria dos projetos modernos é combinar os dois: SVG como declaração principal e PNG como fallback.
Não é complexo de implementar — são poucos elementos no <head> —, mas garante que o ícone do site apareça nítido, consistente e bem adaptado em qualquer contexto onde o usuário o encontrar.
Para projetos mais simples ou com restrições de tempo, um PNG de boa resolução ainda é uma escolha perfeitamente válida e funcional.
