SVG Explicado: De Curiosidade XML a Cidadão de Primeira Classe da Web

Em 2015, escrevi uma resposta no Stack Overflow em Português explicando o que é SVG. A pergunta era simples — alguém queria entender esse formato que vivia ouvindo falar. Naquela época, a maioria dos desenvolvedores ainda usava sprites PNG ou fontes de ícones quando precisava de ícones numa página. SVG parecia uma curiosidade: um formato de imagem baseado em XML que vivia no seu markup. Minha resposta recebeu 17 votos, sinal de que as pessoas realmente precisavam dessa explicação.

Onze anos depois, SVG não é apenas entendido — é o padrão. Aqui está o que expliquei na época, o que mudou desde então, e por que entender as raízes XML do SVG ainda importa em 2026.

A Resposta de 2015: SVG Básico

SVG significa Scalable Vector Graphics (Gráficos Vetoriais Escaláveis). É um formato baseado em XML para descrever gráficos bidimensionais. Diferente de formatos raster (PNG, JPG, GIF), SVG não armazena pixels — armazena instruções. Um círculo é um elemento <circle> com coordenadas e um raio. Um retângulo é um <rect> com largura e altura. O navegador lê essas instruções e renderiza a forma em qualquer resolução que você precisar.

Esse é o principal argumento que enfatizei em 2015: SVG escala para qualquer tamanho sem perder qualidade. Um ícone de 16x16 e um logo do tamanho de um outdoor podem usar exatamente o mesmo arquivo.

Aqui está o tipo de código que mostrei naquela resposta — um retângulo simples:

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="100">
  <rect x="10" y="10" width="180" height="80" fill="#3498db" stroke="#2c3e50" stroke-width="2" />
</svg>

E um círculo:

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <circle cx="50" cy="50" r="40" fill="#e74c3c" stroke="#c0392b" stroke-width="2" />
</svg>

XML puro. Você pode abrir num editor de texto, mudar a cor do fill, ajustar as dimensões, e simplesmente funciona. Também mencionei que SVG é gratuito e aberto — é um padrão W3C, não vinculado a nenhuma ferramenta proprietária.

Para criar SVGs, recomendei o Inkscape, editor vetorial open-source. Para manipulação programática em JavaScript, bibliotecas como RaphaelJS eram populares na época. A resposta cobriu o básico: você pode embutir SVG inline no HTML, referenciar como source de <img>, ou usar como background CSS.

Esse era o nível de conhecimento SVG que a maioria dos desenvolvedores precisava em 2015. Saber o que é, saber que escala, saber que pode editar o XML. Pronto.

O Que Mudou: SVG em 2026

Praticamente tudo sobre como usamos SVG no dia a dia evoluiu. O formato em si não mudou muito — a spec SVG 2 avançou lentamente — mas o ecossistema ao redor se transformou completamente.

Fontes de Ícones Morreram

Em 2015, Font Awesome era rei. Você carregava uma web font contendo centenas de ícones, usava classes CSS para exibí-los, e aceitava os trade-offs: acessibilidade ruim, bugs de renderização, limitação a uma cor, e o peso de carregar uma fonte inteira para vinte ícones.

Bibliotecas de ícones SVG mataram esse padrão. Lucide, Heroicons, Phosphor Icons — todas entregam arquivos SVG individuais ou componentes de framework. Você importa apenas o que usa. Cada ícone é um elemento DOM real que pode estilizar, animar e tornar acessível. O debate “fonte de ícones vs SVG” está encerrado. SVG venceu.

SVG Inline em Frameworks de Componentes

Essa é a maior mudança de workflow. Em 2015, embutir SVG significava copiar e colar XML no seu HTML. Em 2026, todo framework major trata SVG como componente de primeira classe:

---
import IconArrow from '../icons/Arrow.astro';
---

<IconArrow class="w-5 h-5 text-neon" />

import { ArrowRight } from 'lucide-react';

export default function Button() {
  return (
    <button>
      Próximo <ArrowRight size={20} />
    </button>
  );
}

SVG vive dentro da sua árvore de componentes. Você passa props para controlar tamanho e cor. Não é diferente de qualquer outro componente.

Animação SVG com CSS

Em 2015, animar SVG significava recorrer a bibliotecas JavaScript como Snap.svg ou GSAP. Hoje, CSS lida com a maioria das animações SVG nativamente:

.icon-spin {
  animation: spin 1s linear infinite;
}

@keyframes spin {
  from {
    transform: rotate(0deg);
  }
  to {
    transform: rotate(360deg);
  }
}

.path-draw {
  stroke-dasharray: 100;
  stroke-dashoffset: 100;
  animation: draw 1.5s ease forwards;
}

@keyframes draw {
  to {
    stroke-dashoffset: 0;
  }
}

A técnica stroke-dasharray / stroke-dashoffset para animações de desenho de path é especialmente poderosa — você pode fazer ilustrações SVG parecerem se desenhar sozinhas com CSS puro.

SVG Sprites com <use>

Para projetos com muitos ícones, o padrão <use> se tornou standard. Você define todos os ícones numa sprite sheet SVG oculta, depois os referencia por ID:

<!-- Sprite sheet oculta -->
<svg style="display: none;">
  <symbol id="icon-home" viewBox="0 0 24 24">
    <path d="M3 12l9-9 9 9M5 10v10a1 1 0 001 1h3..." />
  </symbol>
</svg>

<!-- Uso em qualquer lugar da página -->
<svg class="icon"><use href="#icon-home" /></svg>

Uma requisição HTTP, zero duplicação, e o navegador faz cache da sprite sheet eficientemente.

SVGO e o Pipeline de Otimização

SVG cru exportado de ferramentas de design é inchado. Figma, Sketch e Illustrator adicionam metadados do editor, atributos redundantes e precisão desnecessária. SVGO (SVG Optimizer) remove tudo isso:

npx svgo icon.svg -o icon.min.svg
# Tipicamente 30-60% de redução no tamanho

Em 2026, SVGO roda automaticamente na maioria dos pipelines de build. Vite, Astro, Next.js — todos têm plugins ou suporte embutido para otimizar SVG em tempo de build.

Acessibilidade

Algo que não cobri em 2015, e que importa. Um <img> com texto alt é acessível por padrão. SVG inline não é — leitores de tela precisam de dicas explícitas:

<svg role="img" aria-label="Início">
  <use href="#icon-home" />
</svg>

Para ícones decorativos, você os esconde da tecnologia assistiva:

<svg aria-hidden="true">
  <use href="#icon-arrow" />
</svg>

Detalhe pequeno, impacto grande para usuários que dependem de leitores de tela.

O Workflow Moderno

Aqui está o workflow típico de SVG em 2026:

1. Design no Figma (ou qualquer ferramenta vetorial)
2. Exportar como SVG
3. Otimizar com SVGO (automatizado no CI ou build)
4. Importar como componente do framework
5. Estilizar com Tailwind ou custom properties CSS
6. Animar com transições/keyframes CSS se necessário
7. Acessível — adicionar role="img" e aria-label, ou aria-hidden="true" para uso decorativo

O handoff designer-desenvolvedor para ícones passou de “aqui está um sprite sheet PNG e um mapa de coordenadas” para “aqui está o arquivo Figma, exporte o que precisar.” O formato é o mesmo dos dois lados. Sem etapa de conversão, sem perda de qualidade.

Conclusão

SVG venceu a guerra dos ícones. Substituiu fontes de ícones, substituiu sprites PNG, e se tornou o formato universal para gráficos vetoriais na web. Mas aqui está o interessante: entender as raízes XML que expliquei em 2015 ainda importa.

Quando SVGO remove um atributo que você realmente precisava, precisa saber o que viewBox faz. Quando um ícone não escala corretamente no seu componente, precisa entender width, height e sistemas de coordenadas. Quando quer animar um path específico, precisa ler a sintaxe <path d="...">.

As ferramentas melhoraram. Os workflows ficaram mais suaves. Mas SVG ainda é XML por baixo dos panos, e os desenvolvedores que sabem disso têm vantagem sobre aqueles que o tratam como caixa preta.

Aquela resposta de 2015 cobriu os fundamentos — e fundamentos têm uma vida útil mais longa que qualquer framework.