SVG gilt als das Format, das „immer scharf" ist. Das stimmt – erklärt aber nur die halbe Geschichte. SVG ist kein besseres PNG, sondern eine grundsätzlich andere Art, Grafik zu beschreiben, mit eigenen Stärken und einer Handvoll Fallstricke, die man kennen sollte, bevor man ein Logo, ein Icon-Set oder eine Illustration ausliefert. Dieser Artikel klärt, wann SVG die richtige Wahl ist, wann ein Rasterformat gewinnt, wie man SVG einbindet, optimiert und absichert.

Was SVG technisch ist

SVG steht für Scalable Vector Graphics und ist eine W3C-Empfehlung. Version 1.0 erschien im September 2001, die bis heute maßgebliche Version 1.1 folgte 2003 (zweite Ausgabe 2011). SVG 2 wird seit Jahren entwickelt, ist aber nach wie vor nicht als finale Recommendation verabschiedet; Browser haben trotzdem einzelne Teile davon übernommen.

Der entscheidende Unterschied zu JPG, PNG oder WebP: Eine SVG-Datei enthält kein Pixelraster, sondern Anweisungen – Pfade, Kreise, Rechtecke, Text, Farben, Transformationen – notiert als XML. Der Browser rechnet daraus beim Anzeigen ein Bild in genau der Auflösung aus, die gerade gebraucht wird.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path d="M12 2 L22 22 L2 22 Z" fill="currentColor"/>
</svg>

Dieses Dreieck ist rund 120 Byte groß und sieht auf einem 5K-Display genauso sauber aus wie auf einem alten Laptop. Das wichtigste Attribut dabei ist viewBox: Es definiert das interne Koordinatensystem und ist die Voraussetzung dafür, dass die Grafik überhaupt frei skaliert. Fehlt die viewBox, verhält sich ein SVG wie ein Bild mit fester Größe – der häufigste Grund dafür, dass „SVG plötzlich nicht responsiv ist".

Weil SVG reiner Text ist, profitiert es stark von Transportkompression. Gzip oder Brotli drücken XML-Markup erheblich zusammen, während PNG, WebP oder AVIF bereits komprimiert sind und über HTTP kaum noch kleiner werden. Ein SVG, das unkomprimiert 8 kB wiegt, kommt über die Leitung oft mit einem Bruchteil davon an – vorausgesetzt, der Server komprimiert image/svg+xml tatsächlich. Das ist eine der häufigsten übersehenen Serverkonfigurationen.

SVG gegen die Rasterformate

EigenschaftSVGPNGWebPAVIF
GrundprinzipVektor (XML)Raster, verlustfreiRaster, beidesRaster, beides
Skalierungbeliebig verlustfreiunscharf beim Hochskalierenunscharfunscharf
Transparenzjajajaja
Fotosungeeignetgroßgutsehr gut
Per CSS gestaltbarja (inline)neinneinnein
Animierbarja (CSS/SMIL)nein (APNG)jaja
Dateigröße hängt ab vonAnzahl der PfadePixelzahlPixelzahlPixelzahl
Braucht srcsetneinjajaja

Die letzten beiden Zeilen sind die eigentlich wichtigen. Bei Rasterbildern wächst die Dateigröße mit der Fläche: Ein Logo in 1000 × 1000 Pixel ist rund viermal so teuer wie dasselbe in 500 × 500, und für hochauflösende Displays braucht man zusätzlich srcset und mehrere Varianten. Bei SVG ist die Anzeigegröße für die Dateigröße völlig egal – es zählt nur, wie komplex die Zeichnung ist. Eine Datei, ein Request, jede Auflösung.

Genau daraus folgt aber auch die Grenze. Eine Illustration mit zehntausend Pfaden, Verläufen und Filtern kann als SVG mehrere hundert Kilobyte groß werden und den Browser beim Rendern spürbar Rechenzeit kosten – Rasterbilder werden dagegen einmal dekodiert und sind dann erledigt. Und ein Foto lässt sich zwar theoretisch in Vektoren nachbauen, das Ergebnis ist aber immer größer und schlechter als ein JPG.

Wann SVG die richtige Wahl ist

  • Logos und Wortmarken – müssen in jeder Größe scharf sein, vom Favicon bis zum Hero-Bereich.
  • Icons und UI-Symbole – wenige Pfade, oft nur eine Farbe, ideal für currentColor und Theming.
  • Diagramme, Charts, Karten – geometrische Formen mit klaren Kanten, oft dynamisch erzeugt.
  • Flächige Illustrationen – solange die Pfadanzahl überschaubar bleibt.
  • Dekorative Hintergründe und Muster – als Data-URI direkt im CSS, ganz ohne zusätzlichen Request.

Und wann nicht:

  • Fotos – immer ein Rasterformat, im Zweifel AVIF oder WebP.
  • Sehr detailreiche Vektorgrafiken – ab einer gewissen Komplexität ist ein vorgerendertes PNG oder WebP kleiner und schneller.
  • Grafiken mit Pixelgenauigkeit bei sehr kleinen Größen – ein 16-Pixel-Icon aus einem für 48 Pixel gezeichneten SVG kann matschig wirken, weil die Kanten nicht auf dem Pixelraster liegen.
  • Kontexte ohne echten SVG-Support – E-Mail-Clients sind hier der klassische Problemfall; für Newsletter führt kaum ein Weg an PNG vorbei.

Die vier Arten, SVG einzubinden

Welche Methode man wählt, entscheidet über Styling, Caching und Sicherheit – und das wird oft unterschätzt.

MethodePer CSS gestaltbarSkripte laufenSeparat cachebarTypischer Einsatz
<img src="x.svg">neinneinjaLogos, statische Grafiken
Inline im HTMLjajanein (Teil des HTML)Icons, interaktive Grafiken
CSS-background-imageneinneinjaMuster, Dekoration
<use href="sprite.svg#id">eingeschränktneinjaIcon-Systeme

Der wichtigste Unterschied: Ein SVG im <img>-Tag wird vom Browser wie ein normales Bild behandelt. Es ist in sich abgeschlossen, kann keine externen Ressourcen nachladen, und enthaltenes JavaScript wird nicht ausgeführt. Dafür kommt auch das CSS der Seite nicht heran – Farben ändern geht nicht.

Inline-SVG ist das Gegenteil: vollständig Teil des DOM, mit CSS gestaltbar (fill: currentColor ist der Klassiker), per JavaScript ansprechbar, aber eben auch Teil des HTML-Dokuments. Es wird nicht separat gecacht und bläht jede Seitenauslieferung auf. Für eine Handvoll Icons ist das völlig in Ordnung, für dreißig identische Symbole auf einer Seite nicht.

Für Data-URIs im CSS gilt eine Stolperfalle: Das Zeichen # muss als %23 kodiert werden, sonst interpretiert der Browser den Rest als Fragment und die Grafik bleibt unsichtbar. Base64 braucht man dafür nicht – URL-kodiertes SVG ist kleiner und bleibt lesbar.

SVG optimieren

SVG-Dateien aus Illustrator, Figma oder Inkscape enthalten regelmäßig ein Vielfaches dessen, was der Browser braucht: Editor-Metadaten, leere Gruppen, unbenutzte <defs>, Kommentare, Ebenennamen und Pfadkoordinaten mit sechs Nachkommastellen. Die wichtigsten Schritte:

  • Mit SVGO aufräumen. Das Standardwerkzeug entfernt Metadaten, führt Pfade zusammen und kürzt Zahlen. Es gibt es als CLI, als Plugin für gängige Build-Tools und als Weboberfläche.
  • Pfadgenauigkeit reduzieren. Koordinaten mit sechs Nachkommastellen sind bei einer 24er-viewBox sinnlos; ein bis zwei Stellen genügen und sparen bei komplexen Pfaden den größten Teil der Bytes.
  • viewBox behalten, feste width/height entfernen. Die Größe gehört ins CSS, sonst skaliert die Grafik nicht mit.
  • Text in Pfade wandeln, wenn Schrift im Spiel ist. Ein <text>-Element wird mit der Schrift gerendert, die der Client gerade hat – auf fremden Systemen sieht das Logo dann anders aus.
  • fill="currentColor" verwenden, damit Icons die Textfarbe erben und im Dark Mode automatisch mitziehen.
  • Gzip oder Brotli für image/svg+xml aktivieren. Der günstigste Gewinn überhaupt, und trotzdem in vielen Konfigurationen vergessen.

Ein Hinweis zur Reihenfolge: Erst optimieren, dann einbetten. Ein Data-URI aus einer unaufgeräumten Datei schleppt den ganzen Editor-Ballast in jedes Stylesheet.

Der Sicherheitsaspekt

SVG ist XML und darf <script>-Elemente, Event-Handler wie onload und externe Verweise enthalten. Das macht es mächtig – und zu einem Angriffsvektor, sobald fremde Dateien ins Spiel kommen.

Konkret heißt das:

  • Nie ein SVG aus unbekannter Quelle inline ins HTML setzen. Enthaltenes JavaScript läuft dann im Kontext der eigenen Domain – klassisches XSS.
  • Im <img>-Tag ist SVG sicher, weil Browser dort kein Skripting zulassen und externe Ressourcen blockieren.
  • Vorsicht bei Nutzer-Uploads. Wird eine hochgeladene SVG-Datei direkt unter der eigenen Domain aufgerufen, rendert der Browser sie als Dokument – inklusive Skripten. Übliche Gegenmaßnahmen sind eine separate Domain für Nutzerinhalte, ein erzwungener Download per Content-Disposition oder eine serverseitige Bereinigung, etwa mit DOMPurify im SVG-Modus.

Wer diese Fragen nicht klären will oder kann, hat eine sehr einfache Alternative: die Grafik rastern. Ein SVG, das in ein PNG oder JPG umgewandelt wurde, kann per Definition kein Skript mehr enthalten.

Barrierefreiheit und Layout

Zwei Details, die in der Praxis regelmäßig fehlen:

Semantik. Ein inline eingebundenes SVG ist für Screenreader zunächst eine Ansammlung von Formen. Grafiken mit Bedeutung brauchen role="img" und entweder ein <title>-Element oder ein aria-label. Rein dekorative Grafiken bekommen umgekehrt aria-hidden="true", damit sie nicht vorgelesen werden. Bei <img src="x.svg"> gilt schlicht die normale alt-Regel.

Layoutstabilität. Ein SVG ohne reservierten Platz verschiebt beim Laden den Inhalt und verschlechtert den Cumulative-Layout-Shift-Wert. Entweder man setzt width und height am <img>-Element oder man definiert im CSS ein aspect-ratio. Das kostet nichts und verhindert einen der häufigsten Core-Web-Vitals-Abzüge.

Fallbacks und Rasterisierung

Der Browser-Support ist praktisch kein Thema mehr: Jeder Browser, der heute noch im Einsatz ist, stellt SVG dar. Fallbacks braucht man aus anderen Gründen:

  • Social-Media-Vorschaubilder. Open Graph und Twitter Cards akzeptieren kein SVG. Für og:image muss ein PNG oder JPG bereitstehen – mit 1200 × 630 Pixeln als üblichem Format.
  • E-Mail. Viele Clients blockieren SVG komplett. Newsletter brauchen Rastergrafiken.
  • Favicons. Moderne Browser akzeptieren SVG-Favicons, aber vor allem in Windows-Kontexten und bei älteren Clients ist eine ICO-Datei weiterhin der sichere Weg.
  • Druck- und Office-Workflows. Word, PowerPoint und diverse Druckdienstleister kommen mit SVG unterschiedlich gut zurecht; ein hochaufgelöstes PNG ist oft der pragmatischere Weg.

Für all diese Fälle rastert man das SVG einmal in der benötigten Größe und liefert daneben weiter die Vektorversion aus. Für die Rastergrafiken auf der Website selbst lohnt anschließend noch der Schritt zu einem modernen Format – PNG zu WebP spart bei flächigen Grafiken regelmäßig deutlich Bytes gegenüber PNG.

Häufige Fragen

Ist SVG immer kleiner als PNG?

Nein. Bei Logos und Icons fast immer, bei komplexen Illustrationen oft nicht. Die Faustregel: Je weniger Pfade und je größer die Anzeigefläche, desto klarer gewinnt SVG. Ab einigen tausend Pfaden sollte man beide Varianten vergleichen – und dabei die komprimierte Größe messen, nicht die auf der Festplatte.

Warum wird mein SVG nicht größer als ein paar Pixel?

Fast immer fehlt die viewBox, oder es sind feste width-/height-Attribute gesetzt, die die Größe festlegen, solange kein CSS sie überschreibt. Mit viewBox plus width: 100% im CSS skaliert die Grafik wie erwartet.

Warum sieht mein SVG-Logo auf fremden Geräten falsch aus?

Typischerweise, weil Text als <text>-Element gespeichert wurde und die passende Schrift dort fehlt. Schrift in Pfade umwandeln löst das dauerhaft. Zweithäufigste Ursache: ein fehlendes xmlns-Attribut, ohne das manche Kontexte die Datei gar nicht erst als SVG erkennen.

Kann ich SVG animieren?

Ja, über CSS-Transitions und -Keyframes, über JavaScript oder über das in SVG eingebaute SMIL. CSS ist heute der übliche Weg, weil es breit unterstützt und gut zu debuggen ist. Von außen steuerbar sind Animationen allerdings nur bei Inline-SVG: Im <img>-Tag greift externes CSS nicht. Im SVG selbst definierte CSS- oder SMIL-Animationen laufen dort aber sehr wohl.

Lohnt sich ein Icon-Sprite noch?

Unter HTTP/2 und HTTP/3 ist das alte Argument „weniger Requests" weitgehend hinfällig. Ein Sprite über <use> hat aber weiterhin einen praktischen Vorteil: eine einzige, separat cachebare Datei statt derselben Pfaddaten in jedem HTML-Dokument.

Fazit

SVG ist kein Allzweckformat, sondern das richtige Werkzeug für eine klar umrissene Klasse von Grafiken: alles, was aus geometrischen Formen besteht und in mehreren Größen scharf sein muss. Dort spart es Requests, Varianten und Wartungsaufwand und liefert nebenbei die beste Darstellungsqualität, die technisch möglich ist. Für Fotos und sehr komplexe Illustrationen bleiben Rasterformate ungeschlagen.

Die drei Dinge, an denen SVG in der Praxis scheitert, sind fast immer dieselben: eine fehlende viewBox, unaufgeräumte Exportdateien und ein Server, der image/svg+xml nicht komprimiert. Wer diese drei Punkte abhakt, Text in Pfade wandelt und fremde SVG-Dateien nie ungeprüft inline einbindet, hat das Format im Griff.

Grafiken konvertieren mit wandlio

Passende Werkzeuge rund um SVG und Rastergrafiken:

  • SVG → PNG: Vektorgrafik mit Transparenz rastern, etwa für Social-Media-Vorschauen
  • SVG → JPG: rastern für Kontexte ohne Transparenz- oder SVG-Unterstützung
  • PNG → WebP: gerasterte Grafiken fürs Web verkleinern
  • PNG → ICO: Favicon für ältere Browser und Windows-Kontexte erzeugen
  • Bild → WebP: beliebige Rasterformate ins moderne Webformat bringen

Bildkonvertierungen laufen bei wandlio direkt im Browser – die Datei verlässt dein Gerät nicht.