1. Componentes SVG inline
Converter cada ícone em um componente (a abordagem que este site automatiza) dá controle total: os ícones herdam a cor via currentColor, aceitam props como size e className e podem ser animados com CSS ou uma biblioteca de animação. Os bundlers eliminam componentes não usados (tree shaking), então você só envia os ícones que importa.
A contrapartida é que a marcação passa a fazer parte do bundle JavaScript. Para algumas dezenas de ícones pequenos isso é irrelevante; para centenas de ilustrações complexas, não.
2. Tags img e fundos CSS
<img src="/logo.svg" alt="Empresa"> é a opção mais simples, e o navegador consegue armazenar o arquivo em cache. Porém o SVG fica isolado do seu CSS, então não dá para mudar a cor no hover ou no modo escuro. Use para logos e ilustrações que nunca mudam.
3. SVGR e loaders em tempo de build
O SVGR (via @svgr/webpack ou vite-plugin-svgr) converte imports de .svg em componentes durante o build. É prático para pastas grandes de ícones, mas adiciona configuração de build e pode se comportar de forma diferente entre bundlers e no Turbopack. Converter uma vez com esta ferramenta gera o mesmo tipo de componente como código-fonte versionado.
4. Sprites SVG e 5. bibliotecas de ícones
Um sprite reúne muitos elementos <symbol> em um arquivo e os referencia com <use href="#icone">. Isso mantém o HTML enxuto, mas complica a renderização no servidor. Bibliotecas como Lucide, Heroicons e Phosphor trazem componentes prontos e são ideais quando o estilo delas combina com o seu design.
Seja qual for o método, siga estas regras de acessibilidade:
- Ícones decorativos ao lado de texto recebem aria-hidden="true".
- Ícones isolados, como um botão só com ícone, precisam de um nome acessível via aria-label no botão ou um <title> dentro do SVG.
- Mantenha um viewBox e dimensione os ícones em em ou rem para que acompanhem o tamanho de fonte do usuário.
- Garanta uma razão de contraste de pelo menos 3:1 para ícones com significado (WCAG 1.4.11).