Was Beim Konvertieren von SVG zu PNG Wirklich Passiert

SVG zu PNG klingt nach einem einzigen, offensichtlichen Arbeitsschritt. Ist es nicht, denn eine SVG enthält keine Pixel - sie enthält Anweisungen zum Zeichnen. In dem Moment, in dem du ein PNG verlangst, stellst du drei Fragen, die die Datei womöglich gar nicht beantwortet: wie groß, in welcher Schrift, und was davon ausgeführt werden darf.

Jeder Konverter beantwortet diese drei Fragen. Die wenigsten sagen dir wie. Hier steht, was tatsächlich passiert, gemessen in aktuellem Chrome, Firefox und Safari.

Frage eins: wie groß ist eine SVG?#

Frag einen Browser nach der Größe einer SVG, und er nennt dir überzeugt eine falsche Zahl.

Wir haben das in Chromium 149, Firefox 151 und WebKit 26.5 mit drei Dateien getestet:

Alle drei Engines sind sich einig, und die zweite und dritte Zeile sind das Problem. 300 x 150 ist ein CSS-Standard für Elemente ohne eigene Größe - derselbe Standard, den ein fehlendes <img> bekommt. Ist eine viewBox vorhanden, behält der Browser die 300 px Breite und rechnet die Höhe aus dem Seitenverhältnis aus.

Ein Icon, das seine Designerin auf 200 x 50 angelegt hat, kommt also als 300 x 75 großes PNG heraus, und nirgends steht, dass ein Standardwert die echte Größe deiner Zeichnung ersetzt hat.

Die Regel, die tatsächlich funktioniert#

Lies die Datei, nicht das DOM:

1. Wenn width und height beide in absoluten Einheiten vorliegen - ohne Einheit, px, pt, mm, in - sind das die echten Maße. Mit 96 dpi umrechnen, 1in sind also 96 Pixel.
2. Sonst, wenn es eine viewBox gibt, nimm deren Breite und Höhe. Das ist das Koordinatensystem der Urheberin. Und es ist der wichtigste Fall, denn width="100%" height="100%" mit viewBox ist genau das, was Illustrator und Figma standardmäßig ausgeben.
3. Sonst steht in der Datei wirklich keine Größe. Irgendetwas muss gewählt werden, und ehrlich ist es, das auch zu sagen, statt stillschweigend 300 x 150 zu erfinden.

Unser SVG-zu-PNG-Konverter zeigt dir für jede abgelegte Datei, welcher der drei Fälle eingetreten ist, und fällt im dritten auf 512 x 512 zurück statt auf den nicht quadratischen Browser-Standard.

Frage zwei: was ist mit meinen Schriften passiert?#

Text in einer SVG ist kein Bild von Text. Er ist eine Zeichenkette plus der Name einer Schrift, die irgendwo anders existieren soll. Eine SVG mit font-family="Brandon Grotesque" enthält nichts von Brandon Grotesque.

Man könnte erwarten, dass eine @font-face-Regel in der SVG das löst. Tut sie nicht. Wir haben eine SVG mit entferntem Webfont in allen drei Browsern getestet und dabei das Netzwerk beobachtet: null Anfragen für die Schrift, in jeder Engine. Der Text wurde trotzdem gezeichnet - in einer Ersatzschrift, mit anderer Laufweite.

Das ist der ganze Mechanismus hinter "warum sieht mein Text nach dem Konvertieren falsch aus". Nur zwei Arten von Text überstehen das unverändert:

• Schriften, die auf dem Rechner installiert sind, der konvertiert. Das heißt, dein PNG kann auf deinem Laptop anders aussehen als auf dem deiner Kollegin.
• Text, der bereits in Pfade umgewandelt wurde. In Illustrator ist das Schrift > In Pfade umwandeln, in Figma Flatten. Sobald jeder Buchstabe ein Pfad ist, kann keine Schrift mehr fehlen.

Wenn der Text zählt, wandle ihn vor dem Export in Pfade um. Das ist die einzige verlässliche Antwort, und es lohnt sich zu wissen, dass dies eine Eigenschaft des Formats ist und kein Mangel eines bestimmten Konverters.

Frage drei: was darf ausgeführt werden?#

SVG ist kein Bildformat in dem Sinne, in dem PNG eines ist. Es ist ein XML-Dokument, und XML-Dokumente können Skripte enthalten. Eine SVG kann <script>-Tags, onload-Handler, Verweise auf entfernte Bilder und @import-Regeln für externe Stylesheets mitbringen.

Deshalb verweigern manche Content-Management-Systeme SVG-Uploads grundsätzlich.

Die gute Nachricht, ebenfalls gemessen: eine SVG über ein <img>-Tag zu rendern statt sie in die Seite zu injizieren, ist eine echte Sandbox. Mit einer Datei, die ein eingebettetes <script>, ein entferntes <image href>, ein xlink:href, ein @import und ein entferntes @font-face trug, führten alle drei Browser kein Skript aus und stellten überhaupt keine Netzwerkanfrage - bestätigt sowohl von innerhalb der Seite als auch von außen.

Ein Konverter, der deine SVG so rendert, kann also zu nichts gebracht werden. Unserer meldet trotzdem, was er gefunden hat, denn zu erfahren, dass dein Logo einen Tracking-Pixel enthielt, ist nützlicher, als ihn stillschweigend zu entfernen.

Das Einzige, was weiterhin gezeichnet wird, ist eine data:-URI - ein Bild, das direkt als Text in der SVG steckt. Das ist so gewollt: es ist in sich abgeschlossen, es gibt nichts zu laden.

Wo das wirklich weh tut#

Nicht bei der Umwandlung. Es tut weh, wenn du SVG-Quelltext nimmst und ihn inline in deine eigene Seite einfügst, wo keiner dieser Schutzmechanismen greift. Wenn du das tust - mit einem Icon-Set oder mit der Ausgabe eines Optimierers - muss die Datei vorher gesäubert werden. Deshalb bereinigt unser SVG-Optimierer bei jedem Durchlauf, ob du darum bittest oder nicht: er gibt dir Quelltext zurück, und Quelltext landet im DOM.

Was sich dadurch nicht ändert#

Zwei Dinge überstehen die Umwandlung exakt, und es lohnt sich, das zu wissen, damit du keine Probleme suchst, die es nicht gibt.

Transparenz. PNG trägt einen vollständigen Alphakanal, also bleibt alles, was deine SVG nicht bemalt, wirklich transparent, und halbtransparente Flächen behalten ihre Deckkraft. Pixelweise in allen drei Engines überprüft.

Schärfe in jeder gewünschten Größe. Das ist der eigentliche Vorteil, von einem Vektor auszugehen. Ein 2x-Export ist kein verdoppeltes Bild - die Zeichnung wird aus der Geometrie neu in der größeren Auflösung gerendert, Kurven bleiben also mathematisch scharf. Deshalb schlägt der Export in 2x das nachträgliche Vergrößern des PNG, und deshalb schlägt ein aus dem Vektor gezeichnetes 16-px-Icon eines, das von 512 px heruntergerechnet wurde.

Das lässt sich messen. Bei einer Marke mit rasterbündigen Kanten ergab das direkte Zeichnen in 16 x 16 genau 141 volle Pixel und kein einziges halbtransparentes; dieselbe Zeichnung aus einem 512-px-Render heruntergerechnet ergab 98 volle und 64 verwaschene Pixel. Vierzig Prozent der Farbe wurden zu Matsch - weshalb unser Favicon-Generator jede Größe einzeln rendert, statt eine große zu verkleinern.

Die Kurzfassung#

• Größe: width/height auslesen, auf die viewBox zurückfallen, und niemals dem glauben, was der Browser meldet.
• Schriften: sie reisen nicht mit. Wandle Text vor dem Export in Pfade um, wenn er zählt.
• Skripte: während der Umwandlung können sie nicht laufen, wohl aber, sobald du SVG-Quelltext in eine Seite einfügst.
• Transparenz und Schärfe: beides bleibt erhalten. Exportiere in der Größe, die du brauchst, statt nachträglich zu skalieren.