SVG für Web, Icons und Logos: Wann Vektor, wann PNG

Ein Logo, das auf dem Smartphone scharf ist, aber auf dem 4K-Monitor verwaschen wirkt, ärgert jeden Designer. Genau dieses Problem löst SVG: Statt fester Pixel speichert das Format mathematische Beschreibungen von Linien, Kurven und Flächen. Der Browser rechnet diese Beschreibung bei jeder Anzeige frisch in Pixel um, passend zur Auflösung des Geräts. Dieser Ratgeber zeigt, warum SVG für Icons und Logos meist die erste Wahl ist, wann du trotzdem ein PNG brauchst und wie du SVG performant ins Web bringst.

Warum SVG für Icons und Logos die erste Wahl ist

Icons und Logos haben drei Eigenschaften, die SVG perfekt bedient: klare Formen, wenige Farben und der Wunsch nach Schärfe auf jeder Größe. Ein Vektor-Icon besteht intern aus Pfaden, also aus Punkten und Kurven. Wenn du dieses Icon von 16 auf 128 Pixel vergrößerst, zeichnet der Browser dieselben Pfade einfach in höherer Auflösung. Es gibt keine Treppchen, keine Unschärfe.

Der zweite Vorteil ist die Dateigröße. Ein typisches Menü-Icon als SVG belegt oft nur 300 bis 800 Byte. Dieselbe Grafik als PNG müsste für Retina-Displays in mehreren Größen vorliegen und käme schnell auf das Drei- bis Zehnfache. Bei einem Icon-Set mit 40 Symbolen summiert sich das spürbar.

Der dritte Punkt ist die Flexibilität. Ein SVG-Pfad lässt sich per CSS einfärben. Du legst ein einziges Icon ab und steuerst die Farbe über die fill-Eigenschaft, je nach Theme hell oder dunkel. Bei PNG bräuchtest du für jede Farbe eine eigene Datei.

Wann ein PNG-Fallback wirklich nötig ist

SVG ist großartig, aber nicht überall einsetzbar. Es gibt klar abgegrenzte Fälle, in denen du auf ein gerastertes PNG zurückgreifen solltest. Der häufigste ist das Vorschaubild für soziale Netzwerke. Open-Graph-Bilder, die etwa Facebook, LinkedIn oder WhatsApp beim Teilen eines Links anzeigen, müssen Rasterformate sein. SVG wird hier nicht verarbeitet. Ein PNG oder JPG in 1200 mal 630 Pixel ist Pflicht.

Auch E-Mail-Newsletter sind ein klassischer Fallback-Grund. Viele E-Mail-Clients, allen voran ältere Versionen von Outlook, zeigen Inline-SVG nicht zuverlässig oder gar nicht an. Für robuste Newsletter rastert man Logos und Header-Grafiken vorab zu PNG.

Ein dritter Fall sind App-Store-Assets und Favicons in bestimmten Größen. Betriebssysteme und Stores verlangen oft exakte Pixelmaße als PNG. Hier gibt das System die Auflösung vor, also liefert man genau diese.

Inline-SVG oder img-Tag: die zwei Einbau-Wege

Es gibt zwei verbreitete Wege, ein SVG in eine Webseite zu bringen, und sie unterscheiden sich grundlegend im Verhalten.

Beim Inline-SVG steht der gesamte SVG-Code direkt im HTML-Dokument. Das sieht so aus:

<button class="icon-button" aria-label="Suchen">
  <svg width="24" height="24" viewBox="0 0 24 24" fill="none">
    <circle cx="11" cy="11" r="7" stroke="currentColor" stroke-width="2" />
    <line x1="21" y1="21" x2="16.65" y2="16.65" stroke="currentColor" stroke-width="2" />
  </svg>
</button>

Der große Vorteil: Du kannst jeden Pfad per CSS ansprechen, Farben über currentColor an die Textfarbe koppeln und beim Hover animieren. Der Nachteil: Der Code bläht das HTML auf und wird nicht separat gecacht. Bei einem Icon, das auf vielen Seiten vorkommt, lädt der Browser es jedes Mal neu mit.

Beim img-Tag liegt die SVG-Datei extern und wird wie ein normales Bild referenziert:

<img src="/icons/suche.svg" alt="Suchen" width="24" height="24" />

Das HTML bleibt schlank, der Browser cacht die Datei und lädt sie nur einmal. Der Preis: Du kannst die internen Pfade nicht mehr per CSS der Seite einfärben oder animieren, das SVG ist von außen eine Blackbox.

Einbau-Methode	Stärke	Schwäche	Bestes Einsatzfeld
Inline-SVG	CSS-Styling, Hover, Animation, currentColor	bläht HTML auf, kein eigener Cache	interaktive UI-Icons, Theme-Farben
img-Tag	schlankes HTML, Browser-Cache, klare Trennung	kein internes Styling möglich	statische Logos, dekorative Grafiken
CSS background-image	Icon per CSS, kein HTML-Markup	nicht im DOM, schlechtere Barrierefreiheit	rein dekorative Hintergründe
SVG-Sprite	viele Icons, ein Request	Setup-Aufwand, use-Referenzen	große Icon-Sets

Performance: was SVG schnell oder langsam macht

SVG ist meist ein Performance-Gewinn, kann aber bei falscher Nutzung bremsen. Drei Faktoren entscheiden.

Erstens die Komplexität der Pfade. Ein einfaches Icon mit zehn Pfaden rendert blitzschnell. Eine detaillierte Landkarte mit 50.000 Pfaden zwingt den Browser, jeden einzelnen Pfad bei jedem Repaint neu zu zeichnen. Ab einer gewissen Komplexität ist ein einmal gerastertes PNG schneller und schont die CPU.

Zweitens der Transport. SVG ist Textdaten und lässt sich hervorragend mit Gzip oder Brotli komprimieren. Ein 8 KB großes SVG schrumpft oft auf 2 KB über die Leitung. Achte darauf, dass dein Server SVG-Dateien komprimiert ausliefert.

Drittens die Anzahl der Requests. Viele einzelne SVG-Dateien per img-Tag bedeuten viele HTTP-Anfragen. Ein SVG-Sprite bündelt alle Icons in eine Datei, die per use referenziert wird. So lädt der Browser nur einmal.

Die Grafik zeigt den Kern: Ein einziges SVG ersetzt einen ganzen Stapel an PNG-Varianten, die du sonst für verschiedene Pixeldichten vorhalten müsstest.

Wann du ein SVG bewusst rasterst

Rastern bedeutet, das Vektor-SVG in feste Pixel umzurechnen und als PNG zu speichern. Das ist kein Rückschritt, sondern in bestimmten Situationen die richtige Entscheidung.

Du rasterst, wenn das Zielsystem keine Vektoren versteht, also bei Open-Graph-Bildern, E-Mail-Grafiken oder App-Icons. Du rasterst auch, wenn ein SVG zu komplex wird und die Render-Last im Browser zu hoch ist. Und du rasterst, wenn du eine definierte, vorhersehbare Pixelausgabe brauchst, etwa für eine Druckvorlage mit fester Auflösung.

Wichtig ist dabei die Zielgröße. Rastere immer in der Größe, in der die Grafik maximal angezeigt wird, und bei Bildschirmen besser mit dem zwei- bis dreifachen Wert, damit das Ergebnis auch auf hochauflösenden Displays scharf bleibt. Ein Logo, das maximal 200 Pixel breit dargestellt wird, exportierst du also als 400 oder 600 Pixel breites PNG.

Ein konkretes Beispiel aus der Praxis

Stell dir eine Produktseite mit Firmenlogo im Header, zwölf UI-Icons in der Navigation und einem Teilen-Button für soziale Netzwerke vor. Die saubere Lösung sieht so aus:

Das Firmenlogo im Header bindest du als img-Tag mit einer SVG-Datei ein. Es ist statisch, soll auf jeder Auflösung scharf sein und profitiert vom Browser-Cache über alle Seiten hinweg.

Die zwölf UI-Icons legst du als Inline-SVG oder als SVG-Sprite an. So kannst du sie per currentColor an das aktive Theme koppeln und beim Hover die Farbe wechseln, ohne zwölf zusätzliche Dateien zu laden.

Das Open-Graph-Vorschaubild für den Teilen-Button erzeugst du als 1200 mal 630 Pixel großes PNG. Hier hilft kein SVG, weil die sozialen Netzwerke nur Rasterformate verarbeiten. Genau für diesen Schritt rasterst du dein Vektor-Design einmalig.

SVG ist die Quelle, PNG ist die Ausgabe für Ziele, die keine Vektoren verstehen. Wer beide Rollen sauber trennt, baut Oberflächen, die überall scharf bleiben.

Mit dem Browser-Tool auf svg-png.de erledigst du den letzten Schritt direkt im Browser: Du lädst dein SVG, wählst die Zielgröße und lädst das fertige PNG herunter. Die Konvertierung läuft lokal auf deinem Gerät, deine Grafik verlässt den Browser nicht.

So gehst du als Web-Entwickler vor

Entscheide bei jeder Grafik zuerst, ob das Ziel ein Browser ist. Lautet die Antwort ja, setze auf SVG: Logos als img-Tag, interaktive Icons als Inline-SVG oder Sprite. Lautet die Antwort nein, weil es um Social Preview, E-Mail oder App-Store-Assets geht, rastere dein Vektor-Design zu PNG in der vom Ziel geforderten Größe. Halte deine SVGs schlank, lass den Server sie komprimiert ausliefern und rastere komplexe Grafiken bewusst, statt den Browser bei jedem Repaint tausende Pfade zeichnen zu lassen. So bekommst du das Beste aus beiden Welten: gestochen scharfe Vektoren überall dort, wo sie funktionieren, und verlässliche PNGs überall dort, wo Vektoren an ihre Grenzen stoßen.