Visualizador SVG gratuito

Sobre o SVG

SVG (Scalable Vector Graphics) é um formato XML para gráficos vetoriais. Diferentemente dos formatos matriciais (PNG, JPG), as imagens SVG se adaptam perfeitamente a qualquer tamanho sem perda de qualidade. São leves, acessíveis e amplamente suportadas pelos navegadores modernos.

Perguntas frequentes

O que é SVG ?

SVG (Scalable Vector Graphics) é um formato de gráficos 2D que usa curvas e caminhos matemáticos em vez de pixels. Isso torna os arquivos SVG independentes de resolução, permanecem nítidos em qualquer tamanho, de pequenos ícones a outdoors.

Qual a diferença entre SVG e PNG ?

O PNG é matricial (baseado em pixels) e tem tamanho fixo, ampliá-lo causa desfoque. O SVG é vetorial (baseado em matemática) e amplia ao infinito sem perda. O SVG é ideal para logotipos, ícones e ilustrações. O PNG é mais adequado a fotos e imagens complexas.

Posso editar o código SVG diretamente ?

Sim, o SVG é texto XML, então você pode editá-lo em qualquer editor de texto. Você pode alterar cores, tamanhos, posições e mais modificando os atributos. Use este visualizador para colar seu código e ver as mudanças instantaneamente.

O SVG venceu a guerra de formatos, duas vezes

Antes de o SVG existir, dois formatos vetoriais concorrentes foram submetidos ao W3C no início de 1998. O PGML (Precision Graphics Markup Language), submetido em 10 de abril de 1998 pela Adobe, IBM, Netscape e Sun, tinha raízes no modelo de imagem PostScript da Adobe. O VML (Vector Markup Language), submetido em 13 de maio de 1998 pela Microsoft, Macromedia, Hewlett-Packard, Autodesk e Visio, usava uma sintaxe próxima do que a Microsoft já distribuía no Office 2000 e no Internet Explorer 5. O W3C não escolheu um vencedor. Em vez disso, formou um SVG Working Group, presidido por Chris Lilley, para projetar um único padrão que substituiria os dois. O primeiro Working Draft público do SVG apareceu em 11 de fevereiro de 1999.

O SVG 1.0 foi publicado como Recomendação do W3C em 4 de setembro de 2001, tendo como editor Jon Ferraiolo (Adobe) e colaboradores da Adobe, IBM, Sun, Apple, Canon, Corel, Kodak, Macromedia, Microsoft, Netscape, Oracle, Sharp, Quark e Xerox, uma das coalizões de fornecedores mais amplas de qualquer especificação do W3C. O SVG 1.1 veio em seguida, em 14 de janeiro de 2003, e continua sendo a base de fato da web moderna; sua Segunda Edição (16 de agosto de 2011) incorporou erratas. O SVG 1.1 dividiu a especificação em módulos e definiu três perfis (Full, Basic, Tiny). O VML continuou a ser distribuído do IE 5 ao 9 e era usado internamente pelo Microsoft Office, mas foi descontinuado no IE 9 (março de 2011) em favor do SVG nativo e estava praticamente morto no IE 11. O SVG 2 é um Working Draft do W3C desde 2016, sem data de Recomendação à vista; os navegadores lançam recursos aos poucos, conforme surge a demanda por interoperabilidade.

O que torna o SVG genuinamente diferente

• É só XML. Um ícone inteiro pode ser uma única linha: <svg viewBox="0 0 24 24"><circle cx="12" cy="12" r="10" fill="currentColor"/></svg>. Como o SVG é texto, ele pode ser comparado com diff e versionado (o Git o trata como código-fonte), gerado no servidor, indexado por mecanismos de busca (o texto dentro de <text> é rastreável), comprimido com eficiência (gzip e brotli adoram tokens XML repetidos, redução típica de 60-80%) e editado em qualquer editor de texto, sem software especializado.
• Independência de resolução. Como os paths do SVG são definidos como curvas e coordenadas matemáticas, não como grades de pixels, um SVG é renderizado de forma idêntica em qualquer nível de zoom e em qualquer densidade de pixels do dispositivo. Não há nenhum recurso Retina «@2x» ou «@3x» para gerenciar. Um único ícone de 2 KB escala de um favicon 16×16 a uma ilustração de destaque 400×400 sem nenhuma perda de qualidade.
• Tamanho de arquivo minúsculo para arte de linha. Um ícone típico de uma cor 24×24 tem ~200-500 bytes como SVG, contra 1-3 KB como PNG transparente. Um logotipo plano de empresa tem 1-5 KB como SVG, contra 15-50 KB como PNG. Um conjunto de ícones de 1.000 símbolos tem ~50 KB como um único sprite SVG, contra 2-5 MB de sprites PNG multi-DPI.
• Inline no HTML e estilizável com CSS. Uma vez que o SVG está inline, cada elemento faz parte do DOM. O CSS pode endereçá-lo: .icon-stroke { stroke: currentColor; stroke-width: 2; }. A única propriedade currentColor é o que faz os sistemas de ícones modernos funcionarem: um ícone herda automaticamente a cor do texto ao redor.
• Animável de três formas diferentes. Animação/transição em CSS (a abordagem moderna preferida), XML declarativo SMIL dentro do SVG (<animate>, <animateTransform>, <animateMotion>) ou JavaScript via DOM do SVG. O SMIL ainda funciona no Chrome, no Firefox e no Safari hoje, depois que o Chrome reverteu seu plano de descontinuação de 2015.
• Manipulável programaticamente. document.querySelector('#chart-bar-3').setAttribute('height', newValue). Essa é a base do D3.js, Vega, Plotly, Highcharts, ApexCharts e do restante do ecossistema de visualização de dados.
• Acessível por padrão. O <title> aparece como dica de ferramenta ao passar o mouse. O <desc> é exposto aos leitores de tela. Os atributos ARIA (role="img", aria-label, aria-labelledby, aria-describedby) funcionam normalmente. Comparado a um elemento <canvas> (uma caixa-preta para a tecnologia assistiva), o SVG é totalmente acessível.

O suporte dos navegadores é universal desde 2011

O SVG nativo chegou no Firefox 1.5 (novembro de 2005), no Opera 9 (junho de 2006), no Safari 3.0 (junho de 2007), no Chrome 1.0 (setembro de 2008) e, por fim, no Internet Explorer 9 (março de 2011), que foi o ponto de inflexão. Antes do IE 9, os sites tinham de distribuir shims de conversão de VML ou o plugin Adobe SVG Viewer para suportar o IE 6-8. O iOS Safari tinha SVG parcial desde o lançamento e suporte completo a partir do iOS 5 (outubro de 2011); o Android chegou lá com o Honeycomb 3.0 (fevereiro de 2011), e o ChromeWebView substituiu o navegador do AOSP por volta do Android 4.4 (2013). O limite inferior prático para o SVG como imagem (<img src="x.svg">) é por volta do fim de 2011. Até 2026, nenhum projeto web realista precisa suportar navegadores sem SVG completo.

O SVG não é apenas um formato de imagem, é um tipo de documento executável

Esta é a coisa mais importante de entender sobre a segurança do SVG. Um SVG malicioso pode incluir blocos <script>, manipuladores de eventos (onload, onclick, onmouseover) ou links <a xlink:href="javascript:...">. Quando um SVG desses é carregado em um contexto ativo (via <object>, <iframe>, navegação do navegador para uma URL .svg ou via inserção com innerHTML), o navegador executa o script. Sites que permitem que SVGs enviados sejam embutidos dessa forma podem sofrer XSS por quem faz o upload.

A tag <img> é o caminho seguro. Quando o SVG é carregado via <img src="x.svg"> ou como uma background-image do CSS, os navegadores rodam o SVG em um modo sandbox, com scripts desabilitados e sem buscas externas. Os scripts internos não são executados, as buscas externas são bloqueadas e o SVG não pode interagir com a página pai. O CSS dentro do SVG é renderizado, mas tudo que poderia ter efeitos colaterais é desabilitado. Esta é a forma recomendada de usar SVG hoje.

Para defesa no servidor, a OWASP recomenda sanitizar os SVGs enviados com o DOMPurify (DOMPurify.sanitize(svg, {USE_PROFILES: {svg: true}})), o svg-sanitizer (PHP), o sanitize-svg (Node) ou o Bleach (Python), removendo <script>, <foreignObject> e todos os manipuladores on*, e rejeitando valores de xlink:href que começam com javascript: ou data:. Definir uma Content-Security-Policy estrita na página que exibe o SVG do usuário e servir os SVGs baixados com Content-Disposition: attachment são acréscimos de cinto e suspensório. Este visualizador é puramente do lado do cliente e o SVG nunca sai do seu dispositivo, mas, se você está embutindo SVG fornecido por usuários em um site público, sanitize-o.

SVG vs. PNG vs. JPG vs. WebP vs. AVIF: quando usar cada um

• Logotipo, ícone, ilustração, diagrama, gráfico, infográfico com texto: SVG. Escala para qualquer tamanho, arquivo minúsculo, recolorível via CSS, o texto continua sendo texto (selecionável, traduzível, indexável).
• Fotografia: JPG (ou AVIF/WebP para stacks modernos). A codificação vetorial de fotos seria enorme.
• Captura de tela: PNG (ou WebP). O raster sem perdas preserva a interface com precisão de pixel.
• Sticker animado de interface: SVG (CSS ou SMIL). Menor e mais nítido que GIF, mais suave que vídeo para loops curtos.

WebP (Google, 2010) e AVIF (AOMedia, 2019) são formatos raster modernos que competem com PNG e JPG, não com SVG: eles não são vetoriais. O modo de falha do SVG são as fotografias e as imagens de tom contínuo: representar cada pixel como uma primitiva vetorial incha o arquivo muito além de um JPEG. Para os casos de ícone e logotipo, o SVG continua imbatível.

Otimizando seu SVG com o SVGO

Um SVG típico exportado do Adobe Illustrator, Sketch, Figma ou Inkscape carrega uma sobrecarga enorme: metadados específicos do editor (<sodipodi:namedview>, <inkscape:groupmode>), nomes de camada padrão e hierarquias de grupos, precisão excessiva nas coordenadas de path (d="M 12.000023 18.999991 ..."), atributos de estilo inline que poderiam ser classes CSS, blocos de comentário que identificam o editor.

O SVGO (SVG Optimizer), escrito originalmente por Kir Belevich em 2012, é a ferramenta da indústria. É uma ferramenta de linha de comando em Node.js com cerca de 50 plugins que lidam com otimizações individuais: removeComments, removeMetadata, removeEditorsNSData, convertColors (transformando rgb(255,0,0) em #f00), convertPathData (colapsando comandos de path e descartando precisão redundante), mergePaths, cleanupNumericValues (arredondando para uma precisão configurável, padrão de 3 casas decimais). A compressão típica é de arquivos 30-70% menores para SVGs feitos à mão a partir de ferramentas de design, ocasionalmente chegando a 80% em exportações do Inkscape por causa dos pesados metadados de editor. O SVGOMG (svgomg.net) é o frontend web do SVGO, feito por Jake Archibald (Google), e a versão de GUI mais usada.

O panorama das bibliotecas de ícones

As bibliotecas de ícones SVG dominam o stack web moderno. Os grandes conjuntos que você encontrará são Heroicons (Tailwind Labs, ~280 ícones, MIT), Lucide (um fork do Feather, ~1.400 ícones), Bootstrap Icons (~2.000), Material Symbols (Google, ~3.000 em vários pesos), Font Awesome 6 (~30.000 gratuitos + Pro), Phosphor Icons (~9.000 em seis pesos) e Tabler Icons (~5.200). O agregador Iconify hospeda mais de 200.000 ícones de código aberto de mais de 150 conjuntos de ícones atrás de uma única API; um desenvolvedor pode escrever <iconify-icon icon="mdi:home"></iconify-icon> e o framework busca apenas o SVG daquele ícone sob demanda. A migração das fontes de ícones (era do Font Awesome 4 / Glyphicons) para os ícones SVG aconteceu por volta de 2017-2019, impulsionada pela acessibilidade, pela recolorabilidade e pela eliminação do FOUT (flash de texto sem estilo, em que a fonte de ícones ainda não tinha carregado).

Mais perguntas

Qual é a diferença entre viewBox e width/height?

O viewBox="0 0 100 100" define o sistema interno de coordenadas de usuário do SVG: seu canvas «natural» tem 100×100 unidades, independentemente do tamanho em pixels renderizado. O width e o height definem o tamanho de exibição renderizado. Com os dois presentes, o SVG escala o viewBox para caber na caixa renderizada. O preserveAspectRatio (padrão xMidYMid meet) controla como a escala lida com incompatibilidades de proporção: meet preserva a proporção e centraliza, none estica, slice recorta para preencher. Definir apenas o viewBox e deixar o CSS controlar width e height é a melhor prática moderna para sistemas de ícones.

Por que meus ícones SVG ficam borrados nas telas?

Quase sempre uma de três causas: (1) o SVG está sendo renderizado em um tamanho fixo de pixels que não corresponde à proporção do viewBox, então o navegador o estica; (2) o SVG foi exportado de uma ferramenta de design com coordenadas subpixel («M 12.5 7.5 L ...»), e o anti-aliasing do navegador está fazendo o melhor que pode com bordas não inteiras; ou (3) o preserveAspectRatio="none" foi definido, o que deixa o SVG esticar arbitrariamente. Corrija garantindo que o contêiner renderizado corresponda à proporção do viewBox, ajustando as coordenadas para inteiros nas opções de exportação da sua ferramenta de design e evitando o preserveAspectRatio="none", a menos que você queira especificamente o esticamento.

Posso usar SVG como favicon?

Sim. O <link rel="icon" type="image/svg+xml" href="icon.svg"> é suportado no Chrome 80+, no Firefox 41+ e no Safari 14+. Um padrão comum é distribuir um favicon SVG para navegadores modernos e um fallback ICO (<link rel="icon" sizes="any" href="favicon.ico">) para clientes mais antigos. Os favicons SVG também podem usar media queries prefers-color-scheme dentro do SVG para alternar automaticamente entre variantes de tema claro e escuro.

O atributo d de path é realmente uma minilinguagem?

Sim, e aprender a dúzia de comandos é a coisa mais próxima de aprender a ler SVG à mão. Os comandos são: M/m (mover para, absoluto/relativo), L/l (linha para), H/h (linha horizontal), V/v (linha vertical), C/c (Bézier cúbica com dois pontos de controle), S/s (cúbica suave, reflete o ponto de controle anterior), Q/q (Bézier quadrática), T/t (quadrática suave), A/a (arco elíptico, o mais complexo) e Z/z (fechar o path). Um d de ícone típico, como M5 12h14M12 5l7 7-7 7, é «mover para (5,12), linha horizontal de 14 unidades, mover para (12,5), linha 7 à direita 7 abaixo, linha 7 à esquerda 7 abaixo», ou seja, uma seta apontando para a direita.

Ferramentas relacionadas