1998: Zwei Vorschläge, ein Web

Die Geschichte von SVG beginnt mit einem klassischen Standardisierungs-Konflikt. Im April 1998 reichten zwei Lager beim W3C konkurrierende Vorschläge für ein XML-basiertes Vektor-Format ein. Adobe, Sun und Netscape hatten gemeinsam PGML (Precision Graphics Markup Language) entworfen — eine XML-Syntax, die stark vom PostScript-Modell inspiriert war und Adobes professionelle Grafik-Tradition weiterführte. Microsoft, Macromedia, HP und Visio hingegen brachten VML (Vector Markup Language) auf den Tisch — pragmatischer, näher an Office-Anwendungen orientiert und bewusst einfach gehalten.

Das W3C verweigerte beiden Vorschlägen die direkte Übernahme und bestellte stattdessen eine eigene Arbeitsgruppe ein, die ein neues Format aus beiden Quellen synthetisieren sollte. Vorsitz hatte Chris Lilley, technischer Direktor der W3C-Grafik-Aktivität. Aus der Mediation entstand SVG (Scalable Vector Graphics) — kein reines Adobe-Format, kein reines Microsoft-Format, sondern ein Kompromiss, der allen Beteiligten Eigentumsrechte abkaufte.

2001: SVG 1.0 wird Standard

Es dauerte drei volle Jahre, bis aus den konkurrierenden Vorschlägen eine fertige Spezifikation wurde. Am 4. September 2001 ratifizierte das W3C SVG 1.0 als offizielle Recommendation. Das Format brachte vier strukturelle Eigenschaften mit, die später seine Dominanz absicherten: Text-basiertes XML (lesbar in jedem Text-Editor, indexierbar von Suchmaschinen), Auflösungs-Unabhängigkeit(rendert in jeder Größe pixelgenau), Einbettung in HTML (kein Browser-Plugin nötig) und ein DOM-fähiges Animations-Modell, das später Web-Animationen prägen sollte.

Eine subtile Stärke: SVG ist von Anfang an programmatisch manipulierbar. Jedes Element ist ein DOM-Knoten, jedes Attribut per JavaScript zugreifbar. Das machte SVG zur natürlichen Grundlage für Daten-Visualisierungs-Bibliotheken wie D3.js (2011), und es ist der Grund, warum heute praktisch alle Chart-Tools (Highcharts, Recharts, Chart.js mit SVG-Renderer) auf SVG aufsetzen.

2001–2010: Der lange Schatten des Internet Explorer

Trotz Standardisierung blieb SVG ein Jahrzehnt lang ein Nischen-Format — und das allein wegen Microsofts Verweigerung. Internet Explorer 6, 7 und 8 rendern SVG schlicht nicht. Wer SVG in den frühen 2000ern im Web einsetzen wollte, brauchte das proprietäre Adobe SVG Viewer Plugin (dessen Entwicklung Adobe 2009 einstellte) oder griff auf Microsofts hauseigenes VML zurück — ironischerweise das Format, das im PGML-Konflikt eigentlich verloren hatte.

Erst Internet Explorer 9 (2011) brachte native SVG-Unterstützung. Damit war SVG nach einer 10-jährigen Wartezeit endlich in allen Mainstream-Browsern angekommen. Diese Verzögerung ist der Hauptgrund, warum SVG sein eigentliches Web-Comeback erst ab 2012 erlebte — pünktlich zur Retina-Display-Welle, die genau das forderte, was SVG strukturell mitbrachte: scharfe Darstellung in beliebiger Auflösung.

SVG und die Retina-Revolution (2012–2015)

2012 lieferte Apple das MacBook Pro mit Retina-Display aus, ein Jahr später folgten iPads und iPhones im selben Stil. Plötzlich rendern Web-Bilder, die für 96-dpi-Displays gedacht waren, sichtbar unscharf. Die übliche Lösung — PNGs in mehreren Größen mitsrcset ausliefern — funktionierte für Fotos, aber für UI-Icons und Logos war SVG strukturell überlegen. Ein einziges 2-KB-SVG ersetzte 5 PNG-Varianten, dynamische Farbänderung via CSS war möglich, und der Browser-Cache musste nur einmal gefüllt werden.

Ab 2014 begannen UI-Bibliotheken (Bootstrap 4, Material Design Icons) ihre PNG-Sprite- Sheets durch SVG-Symbol-Sets zu ersetzen. Bis 2018 war SVG für Icons und Logos der De-facto-Standard. Eine moderne Praxis dazu zeigt unser SVG-vs.-PNG-vs.-JPG-Vergleich für Icons.

Das SVG-2-Drama (2012–2018)

Während SVG technisch florierte, lief seine Spezifikations-Entwicklung in eine Sackgasse. Die Arbeitsgruppe hatte sich SVG 2 vorgenommen — eine modernisierte, aufgeräumte Version mit Web-Animations-API-Integration, vereinfachten Pfad-Befehlen und besserer HTML5-Verzahnung. Was als zweijähriges Refinement begann, dauerte sechs Jahre. Im Prozess wurden Features eingebaut, gestrichen, modifiziert und wieder gestrichen — ein klassisches W3C-„Boil-the-ocean"-Projekt.

Browser-Hersteller setzten in der Zwischenzeit eigene Features ohne Spec-Konsens um. Das Ergebnis: SVG 2 ist 2024 als Candidate Recommendation veröffentlicht worden, aber kein Browser implementiert es vollständig. Das in der Praxis verwendete „SVG" ist eine Mischung aus SVG 1.1 plus pragmatischen Browser-Erweiterungen. Die Spezifikations-Welt ist noch nicht eingeholt — und das beschäftigt SVG-Tooling-Entwickler bis heute.

Tooling: Inkscape, SVGO, Figma

Drei Werkzeuge prägen das SVG-Ökosystem seit zwei Jahrzehnten. Inkscape (2003, GPL-lizenziert) ist die wichtigste Open-Source- SVG-Authoring-Software, von Sodipodi abgespalten und seit Version 1.0 (2020) reif für professionelle Workflows. SVGO (2012, Node.js) ist der Standard- Optimizer, der unnötige Editor-Metadaten, Whitespace und numerische Präzision entfernt — typische Größeneinsparung 40–70 %. Figma (2016) machte SVG-Export aus dem Design-Tool zur Selbstverständlichkeit und bestimmt heute die Erwartungshaltung an „sauberes SVG".

Unser SVG-Optimierungs-Beitrag erklärt die praktische SVGO-Pipeline und zeigt, was typische Figma-Exports wegwerfen können, ohne dass ein Pixel anders aussieht.

2020–2026: Lottie, Variable Color Fonts und SVG als Fallback

Mit dem Aufkommen von Lottie (Airbnb 2015, JSON-basierte After-Effects-Animationen) und variable color fonts (COLR/CPAL für Emojis und farbige Icons) hat SVG in einigen Nischen Konkurrenz bekommen. Lottie ist effizienter für komplexe Animationen; Color-Fonts liefern UI-Icons als Schrift, was DOM-Aufwand spart. SVG bleibt aber strukturell unangefochten für statische Vektoren, interaktive Charts und alles, was direkt in das HTML-DOM eingebettet wird.

Eine zweite Wiederbelebung erlebt SVG durch Server-Side-Rendering: Plattformen wie Next.js (siehe unseren Hinweis in Icon-Studio-Beitrag) inlinen SVG-Icons direkt in den HTML-Stream, was zusätzliche Roundtrips spart und die First-Contentful-Paint-Zeit verbessert — relevant für Core Web Vitals.

Wann SVG die richtige Wahl ist

  • Logos und Markenzeichen. Auflösungs-Unabhängig, in CSS recolorierbar, ein einziges Asset für alle Größen.
  • UI-Icons. Auch hier strukturell überlegen — siehe die vier in unserem Icon Studio eingebundenen react-icons-Sammlungen.
  • Charts und Daten-Visualisierungen. DOM-zugängliche Achsen, Punkte, Linien, die per JavaScript animierbar sind.
  • Karten und Geo-Daten. Tools wie D3.js und Mapbox GL nutzen SVG für Overlay-Layer.
  • Print-Workflows. SVG lässt sich verlustfrei zu PDF konvertieren und in Druckprozesse einbinden — siehe SVG zu PNGfür die Raster-Konvertierung.

Wann SVG die falsche Wahl ist: bei Fotos (unsinnig — Raster gewinnt strukturell), bei extrem komplexen Pfaden (10 000+ Bezier-Punkte produzieren DOM-Overhead) und bei Animationen, die mehr als simple Übergänge brauchen (hier ist Lottie effizienter).

Quellen

W3C SVG 1.1 (Second Edition) Recommendation · W3C SVG 2 Candidate Recommendation · W3C PGML-Submission (1998) · W3C VML-Submission (1998) · SVGO-Projekt · Inkscape-Projektseite · Chris Lilley, „A Brief History of SVG", W3C-Blog 2011.