SVG-Optimierer — Vektor-Grafiken kleiner & schneller

Was macht dieses Tool genau?

Du legst eine SVG-Datei ab (oder einen Ordner voll davon im Bulk-Modus), das Tool schickt sie durch einen spezialisierten SVG-Optimierer und zeigt dir das Ergebnis: einen kleineren Quelltext, eine Render-Vorschau gegen das Original und die Byte-Ersparnis. Die Optimierung läuft im Browser über eine Pure-JavaScript-Optimierer-Engine — kein Upload, kein Konto, kein Tracking. Output: eine einzelne optimierte Datei oder ein ZIP-Archiv im Bulk-Modus. Die Bedienung ist absichtlich schlank: vier Voreinstellungen, ein „Eigene“-Modus für Profis und zwei Output-Schalter (Lesbar formatieren, Mehrfach-Durchlauf). Alles andere liegt hinter der „Eigene“-Toggle-Liste, damit Erstnutzer nicht in zwanzig Checkboxen ertrinken.

Die Ersparnis variiert dramatisch mit der Art der SVG-Authoring. Ein handgeschriebener Pfad mit drei-Dezimal-Koordinaten ohne Schmuck schrumpft um 5–15 %. Ein Logo, das aus einem Vektor-Programm mit Editor-Namensräumen, Kommentaren, Metadata und acht-Dezimal-Präzision exportiert wurde, sinkt routinemäßig um 60–80 %. Ein Workflow, der eine SVG durch ein Screen-Recording-Tool und einen Editor schickt, kann Dateien produzieren, die zu 90 % Ballast sind — wir haben 200-KB-Icons gesehen, die auf 25 KB schrumpfen, ohne dass ein einziger Pixel sich im Render ändert.

Warum SVGs in 2026 überhaupt optimieren?

Drei Gründe, die sich addieren. Erstens First-Paint-Performance: jedes Kilobyte inline-SVG verzögert deinen Hero-Render. Moderne Websites inlinen 8–20 Icons in ihrer Navigation; 3 KB pro Icon zu sparen entlastet die Critical-Path-Payload um 60 KB. Zweitens Gzip-Ratio: Optimierer sortieren Attribute alphabetisch (sortAttrs), was die Kompressor-Fenster verbessert — die optimierte SVG ist nicht nur roh kleiner, sie komprimiert auch besser. Drittens Build-Pipeline-Integration: SVGs, die durch dieses Tool gelaufen sind, bringen schon den Editor-Ballast nicht mehr mit, sodass Downstream-Werkzeuge (Icon-Font-Builder, Sprite-Generatoren, Framework-Loader) saubereren Input bekommen.

Es gibt auch einen Privacy-Aspekt, der viele überrascht. Design-Tool-Exporte betten oft User-Metadata in die SVG ein: den Benutzernamen des Authors, den Dateipfad auf der lokalen Festplatte, den Working-Timestamp des Editors, manchmal sogar nichtgebrauchte Referenzbilder als Data-URIs. Kommentare und Metadata zu entfernen heißt, dass diese Information nicht mehr mit deinem Asset reist. Dasselbe gilt für die Publikation eines Firmen-Logos aus einem internen Workflow — der Export sollte nicht die Ordnerstruktur deines Laptops mitschleppen.

Wie unterscheiden sich die vier Voreinstellungen?

Web ist Default und am aggressivsten — das, was die meisten für Icons und Illustrationen im Browser brauchen. Sie entfernt Kommentare, Metadata, <title>, <desc>, Editor-Namensräume, DOCTYPE und den XML-Prolog. Sie kürzt IDs, rundet Zahlenwerte auf drei Dezimalstellen (in Icon-Größe meist unsichtbar), kürzt Farben (#ffffff → #fff, rgb(255,0,0) → red), konvertiert Formen zu Pfaden, wenn das Bytes spart, fasst Pfade zusammen und kollabiert redundante Transformationen und Gruppen. Die viewBox wird nicht entfernt; intrinsisches Sizing ist zu oft wichtig, um das stillschweigend zu riskieren. Erwartete Reduktion: 40–80 % bei typischen Design-Tool-Exporten.

Figma-Safe behält IDs unverändert. Vektor-Design-Tools referenzieren Formen über IDs, wenn du Symbol-Varianten oder Component-Overrides einrichtest; werden die IDs in einer reimportierten SVG umbenannt, bricht die Varianten-Verdrahtung. Außerdem bleiben <title> und <desc> (Barrierefreiheit), und Pfad-Merging wird übersprungen (das Design-Tool importiert jeden Pfad als separates Objekt — verschmolzene Pfade flachen die Layer-Panel-Hierarchie ab). Erwartete Reduktion: 30–60 %.

Editor-Safe ist die Round-Trip-Voreinstellung für SVGs, die du weiter in einem Vektor-Programm bearbeiten willst. Sie erhält Kommentare, Editor-Namensräume, IDs, Titel, Beschreibungen, Layer-Marker — alles, was ein Editor zum Wiederherstellen seines Working-States braucht. Es laufen nur die sichersten Minifikationen: Attribut-Aufräumen, Zahlen-Rundung, Farb-Kürzung und Attribut-Sortierung. Erwartete Reduktion: 5–20 %. Nutzen, wenn du Assets im Working-Folder optimierst, nicht den Production-Export.

Eigene lässt dich exakt die Optimierungen anhaken, die laufen sollen. Die Liste ist als zweispaltiges Grid mit beschreibenden Labels (keine Plugin-Namen — nur, was die Optimierung tut). Der Start-Zustand entspricht der Web-Voreinstellung; du kannst einzelne Einträge abwählen, fortgeschrittene Schalter wie „viewBox entfernen“ oder „width/height entfernen“ aktivieren und beliebig oft neu durchlaufen. Diesen Modus brauchst du, wenn eine Regression aufgetaucht ist: die eine Optimierung abwählen, die das Icon kaputtgemacht hat, und neu rechnen.

Wofür ist die Vorher-Nachher-Vorschau?

Visuelle Regression ist der Fehlerfall, den aggressive SVG-Optimierung am besten versteckt. Ein Pfad, der auf 24 px gut aussah, beginnt bei 96 px zu wackeln, weil die Drei-Dezimal-Rundung einen Kontrollpunkt vom Anker geschoben hat. Ein Verlauf, der einen fehlenden Stop referenziert hat, wird nach dem Entfernen ungenutzter <defs> als Volltonfarbe gerendert. Ein clipPath, der von einer ID abhing, wurde umbenannt, und der Clip schneidet jetzt nichts mehr. Keines dieser Probleme zerstört die SVG; alle drei ändern, wie sie sich darstellt.

Die Vorschau rendert beide Versionen in einer abgeschotteten Sandbox. Du siehst links das Original, rechts das Optimierte, beide auf dieselbe Box skaliert. Mit der Maus über die Details fahren, um Details zu vergleichen. Wenn das Optimierte anders aussieht, ist der Fix meistens: konservativere Voreinstellung wählen, Float-Präzision im Modus „Eigene“ erhöhen oder die spezifische Optimierung deaktivieren, die den Unterschied verursacht hat (z.B. „viewBox entfernen“, „Formen zu Pfaden konvertieren“, „IDs aufräumen / kürzen“). Die Vorschau verändert deinen Quelltext nicht — sie ist ein reiner Render-Vergleich.

Wie funktioniert der Bulk-Modus?

Mehrere SVG-Dateien gleichzeitig ablegen oder auswählen. Das Tool liest jede in den Speicher, wendet die aktive Voreinstellung auf jede an und zeigt dir eine Per-Datei-Liste mit Größendelta. Eine Batch-Zusammenfassung über der Liste zeigt gesparte Bytes insgesamt, gewichtete Reduktion in Prozent und Gesamt-Optimierungszeit. Du lädst alle optimierten Dateien als ein ZIP-Archiv herunter, kopierst einzelne Quelltexte oder speicherst Dateien einzeln.

Der Bulk-Modus ist der richtige Weg, wenn du eine Icon-Bibliothek geerbt hast oder einen Ordner Illustrationen sauber in deinen Build aufnehmen willst. Die Web-Voreinstellung auf einer 200-Icon-Bibliothek spart typisch 60–80 % der Gesamt-Bytes — das ist eine spürbare Lighthouse-Verbesserung für jede Seite, die sie inline ausliefert. Pro-Datei-Ausreißer (eine SVG, die nicht geschrumpft ist, oder leicht gewachsen) sind in der Liste markiert, damit du sie kontrollieren kannst; meist sind das bereits minifizierte Inputs, an denen nichts mehr zu sparen war.

Was steht im Netzwerk-Tab, während das Tool optimiert?

DevTools öffnen, Netzwerk-Tab, eine 1-MB-SVG ablegen und beobachten. Du siehst null ausgehende Requests für die Optimierung selbst. Der Optimierer wird einmal nach dem ersten Seitenidle dynamisch nachgeladen und vom Browser gecached; alle weiteren Dateien nutzen das in-memory geladene Modul. Es gibt keinen Analytics-Ping, kein Logging-Endpoint und keine Background-Sync- oder Reporting-API, die manche Tools nutzen, um Daten leise abzuziehen.

Das ist kein Marketing-Versprechen, sondern eine verifizierbare Eigenschaft des Seitenaufbaus. Der Optimierer ist ein JavaScript-Modul, das in deinem Tab läuft; SVG-Quellen werden mit der FileReader-API des Browsers gelesen; Outputs werden im Speicher konstruiert und in Blob-URLs gehängt, die der Browser bis zum Schließen des Tabs lokal behält. Wir nutzen keine IndexedDB-Persistenz, keinen Service-Worker-Storage deiner Dateien und keine Clipboard-Hooks außer dem expliziten „Kopieren“-Button, den du drückst.

Wann ist dieses Tool nicht die richtige Wahl?

Ein paar Fälle, wo du zu einem anderen Tool greifen solltest. SVG-zu-PNG-Rasterisierung: dieses Tool optimiert SVG-als-SVG, es rendert nicht zu PNG. Pfad-Vereinfachung (Ramer-Douglas-Peucker): dieses Tool strafft Pfad-Koordinaten, ändert aber nicht die Pfad-Topologie. Bitmap-zu-SVG-Vektorisierung: das ist ein komplett anderes Problem. Editor-Qualität interaktive Bearbeitung: das hier ist ein One-Shot-Optimierer, keine Working-Canvas. WebP/AVIF-Konvertierung: nutze unseren Bild-Format-Konverter für Rasterformate und unseren Bild-Größe-ändern für Dimensionsänderungen.

Worin dieses Tool wirklich gut ist: saubere, kleine, vorhersehbare SVG-Icons in deinen Production-Build zu schicken, ohne Treue zu verlieren, ohne irgendwas hochzuladen und ohne ein CLI lernen zu müssen. Wer sowieso auf der Kommandozeile zu Hause ist, kann denselben Optimierer auch als CLI nutzen — aber für den Workflow „17 Logos im Slack-Thread, bis zum Mittagessen sauber“ ist die Browser-Variante schneller.

Wie passt SVG-Optimierung in eine Build-Pipeline?

Drei übliche Integrationspunkte. Zur Authoring-Zeit (dieses Tool oder die äquivalente CLI auf einem Ordner): du optimierst SVGs, bevor sie in die Versionskontrolle wandern, damit jeder Commit sauberen Quelltext ausliefert. Das ist der reibungsärmste Ansatz für selten geänderte Icon-Bibliotheken. Zur Build-Zeit (CLI in package.json postinstall oder Build-Script): du behältst den verbosen Quelltext für die Editor-Freundlichkeit und strippst erst auf dem Weg in die Produktion. Funktioniert gut, wenn Designer regelmäßig Updates abliefern und der Quelltext nah am Export bleiben soll. Zur Request-Zeit (Server-Middleware, die on-the-fly optimiert): selten, meist Overkill — die Ersparnis rechtfertigt nicht die CPU-Kosten, dasselbe Icon bei jedem Request neu zu optimieren.

Dieses Tool passt exakt zum ersten Integrationspunkt: ein gelegentlicher manueller Lauf, der production-ready SVG produziert. Der Output, den du kopierst oder herunterlädst, ist dieselbe Byte-Sequenz, die eine CLI-Optimierung mit derselben Plugin-Auswahl produzieren würde — du kannst also im Browser vor-optimieren und das Ergebnis committen, ohne dass deine CI das nochmal tun muss. Die Web-Voreinstellung entspricht den verbreitetsten CLI-Defaults, der Modus „Eigene“ listet alle Optionen erschöpfend auf, und die Vorher-Nachher-Vorschau bestätigt, dass keine Überraschung in den Commit landet.

Was misst die Reduktions-Prozentzahl genau?

Die Prozentzahl über dem Output entspricht (originalbytes − optimierte_bytes) / originalbytes, berechnet auf UTF-8-codierter Byte-Länge. Das ist die Dateigröße, die du auf die Festplatte schreiben oder an einen Browser ausliefern würdest, nicht die In-Memory-Repräsentation. Für inline-SVGs in HTML ist das auch exakt die Byte-Ersparnis am Dokument-Download — jedes hier gesparte Byte ist ein Byte weniger, das der Browser parsen muss, bevor er dein Icon rendert.

Zwei Dinge erfasst die Prozentzahl nicht. Erstens Gzip-Ratio-Verbesserungen: durch das alphabetische Sortieren der Attribute und das Normalisieren von Whitespace komprimiert die optimierte SVG oft besser, als das rohe Größendelta vermuten lässt. Empirisch addiert das nochmal 10–20 % oben drauf, sobald gzip greift. Zweitens Parse-Time-Ersparnis: eine kleinere SVG mit zusammengefassten Pfaden ist für den SVG-Renderer des Browsers schneller zu parsen und zu zeichnen. Wir messen die Parse-Zeit hier nicht (sie ist maschinenspezifisch), aber die Beziehung ist monoton — kleinere SVGs rendern schneller.

Wo findest du den Standard und mehr Hintergrund?

• W3C-SVG-Spezifikation — der Standard, an den sich der Optimierer hält.
• MDN SVG-Tutorial — wie SVGs im Browser rendern und welche Attribute Browser respektieren.
• Wikipedia: Scalable Vector Graphics — historischer Kontext und Format-Überblick.

Eine SVG optimieren, den Byte-Zähler fallen sehen, ein kleineres Bundle ausliefern. Kein Upload, kein Konto, kein Tracking — verifizierbar im Netzwerk-Tab deiner Browser-DevTools.