SVG wird im Browser nicht angezeigt? Häufige Ursachen
Warum dein SVG ein defektes Bildsymbol anzeigt (oder gar nichts)
SVG-Dateien sollten einfach sein. Als unendlich skalierbare Alternative zu Rasterformaten sind sie normalerweise zuverlässig. Aber wenn ein SVG die Anzeige verweigert, ist der Fehler oft still und verwirrend. Du siehst ein defektes Bildsymbol, ein leeres weißes Rechteck oder einfach nur einen leeren Bereich, wo deine Grafik sein sollte. Ein beschädigtes JPEG sieht zumindest offensichtlich kaputt aus; ein fehlerhaftes SVG kann in einem Texteditor perfekt aussehen und trotzdem nichts in Chrome, Firefox oder Safari anzeigen. Die Probleme lassen sich meist auf einige wenige Ursachen zurückführen: ein falscher MIME-Typ vom Webserver, fehlerhaftes XML innerhalb der Datei, Sicherheitspolicies, die Inline-Code blockieren, oder Größenprobleme, die das SVG mit einer nicht sichtbaren Größe rendern. Jedes Problem hat eine andere Lösung, und das Verwechseln der Ursachen wird Stunden verschwenden. Dieser Leitfaden führt dich durch jede Ursache mit den spezifischen Einstellungen und Attributen, die du überprüfen musst, und nicht nur mit vagen Ratschlägen wie „validiere deine Datei“. Eine wichtige Unterscheidung, bevor wir beginnen: Einige SVG-Probleme entstehen bereits im Design-Tool (Illustrator, Figma) während des Exports, während andere während der Dateikonvertierung auftreten. Wenn du ein Online-Tool verwendet hast, um eine Datei in SVG zu konvertieren und sie dabei kaputtgegangen ist, ist das eine andere Art von Problem als ein perfektes SVG, das dein Server falsch konfiguriert. Wir werden sicherstellen, zwischen den beiden zu unterscheiden.
Falscher MIME-Typ: Das serverseitige Problem, das die meisten Entwickler übersehen
Wenn du ein `<img>`-Tag oder CSS `background-image` verwendest, um ein SVG anzuzeigen, prüft der Browser den vom Server gesendeten `Content-Type`-Header. Wenn dieser Header `text/plain` oder `application/octet-stream` anstelle des korrekten `image/svg+xml` lautet, weigern sich die meisten Browser einfach, das Bild zu rendern. Die Datei selbst könnte fehlerfrei sein. Dies ist eine der häufigsten Ursachen für defekte SVGs in der Produktion und ein „Geist“ in der lokalen Entwicklung. Warum? Weil du lokal wahrscheinlich die Datei nur von der Festplatte öffnest und sie nicht über einen Server bereitstellst. Das Problem taucht erst nach dem Deployment auf. Um dies zu diagnostizieren, öffne die DevTools deines Browsers (F12), wechsle zum Tab „Netzwerk“ und lade die Seite neu. Finde dein SVG in der Anfrageliste, klicke darauf und schau dir die Antwort-Header an. Die Zeile `Content-Type` muss `image/svg+xml` lauten. Wenn dort etwas anderes steht, hast du dein Problem gefunden. Die Lösung liegt auf dem Server, nicht in der Datei. Auf Apache kannst du dies beheben, indem du `AddType image/svg+xml .svg .svgz` zu deiner `.htaccess`-Datei hinzufügst. Für Nginx-Benutzer füge `image/svg+xml svg svgz;` innerhalb des `types`-Blocks deiner `nginx.conf` hinzu. Wenn du IIS verwendest, musst du den Internet Information Services Manager nutzen, um eine MIME-Typ-Zuordnung für die `.svg`-Erweiterung zu `image/svg+xml` hinzuzufügen. Wenn du eine verwaltete Plattform wie Netlify oder Vercel verwendest, wird dies in einer Konfigurationsdatei (`netlify.toml` oder `vercel.json`) gehandhabt. Netlifys Syntax verwendet beispielsweise einen `[[headers]]`-Block, um den `Content-Type` für einen bestimmten Pfad festzulegen. Es ist eine Fünf-Minuten-Korrektur, die dir Stunden der Frustration ersparen kann, aber nur, wenn du weißt, dass du im Netzwerk-Panel nachsehen musst.
Fehlerhaftes XML: Wenn die SVG-Datei selbst das Problem ist
Ein SVG ist ein XML-Dokument, was bedeutet, dass es strengen Parsing-Regeln folgt. Ein fehlendes schließendes Tag, ein nicht-escaped-Kaufmanns-Und oder eine doppelte `id` kann dazu führen, dass die gesamte Datei in einigen Browsern stillschweigend fehlschlägt. Hier ein Tipp: Wenn dein SVG in Chrome, aber nicht in Firefox gerendert wird, ist fehlerhaftes XML der Hauptverdächtige. Firefox ist bei XML-Fehlern viel expliziter. Um es selbst zu sehen, ziehe die SVG-Datei direkt in ein Firefox-Fenster. Wenn das XML kaputt ist, zeigt dir Firefox eine klare Fehlermeldung an, komplett mit Zeilen- und Spaltennummer: „XML Parsing Error: not well-formed at line 47, column 12.“ Das ist deine Schatzkarte. Öffne die Datei in einem Texteditor wie VS Code und gehe genau zu dieser Stelle. Wonach suchst du? Oft ist es ein Kaufmanns-Und (`&`) in einem Link, das als `&` hätte geschrieben werden sollen. Oder du findest ein nicht geschlossenes `<path>`- oder `<g>`-Element. Kodierungsprobleme sind ein weiterer Klassiker, bei dem ein Design-Tool Zeichen außerhalb des Standard-ASCII-Bereichs exportiert, ohne UTF-8 zu deklarieren. Deine SVG-Datei sollte immer mit `<?xml version="1.0" encoding="UTF-8"?>` beginnen, wenn sie nicht-ASCII-Zeichen enthält. Ältere Versionen von Adobe Illustrator liebten es, Dateien mit proprietären XML-Namespaces zu exportieren. Obwohl technisch nicht ungültig, fügt dies unnötiges Gewicht hinzu und kann manchmal Parser verwirren. Das Ausführen dieser Dateien durch einen Optimierer wie SVGO entfernt diese Namespaces typischerweise, was gut ist. Die Gefahr besteht darin, dass das Aussehen der Grafik irgendwie von diesen proprietären Attributen abhing, in welchem Fall das Bereinigen der Datei sie unerwartet beschädigen könnte. Wenn du eine Datei mit CocoConvert in SVG konvertiert hast und die Ausgabe XML-Fehler aufweist, lass uns dies bitte über den Feedback-Button auf der Ergebnisseite wissen. Wir spüren solche Konvertierungsartefakte aktiv auf und beheben sie.
Inline-SVG und Content Security Policy Konflikte
Das direkte Einfügen von SVG-Markup in dein HTML ist eine leistungsstarke Technik, birgt aber einen großen Haken: Das SVG wird Teil des DOM. Das bedeutet, es unterliegt jetzt der Content Security Policy (CSP) deiner Seite. Eine strenge CSP kann Teile deines SVGs stillschweigend deaktivieren, was zu Verwirrung führt. Dies gilt insbesondere für SVGs, die `<script>`-Elemente, `<style>`-Blöcke für Animationen oder `<use>`-Elemente enthalten, die auf externe Symboldefinitionen verweisen. Eine gängige CSP-Direktive wie `script-src 'self'` blockiert die Ausführung aller Inline-Skripte innerhalb deines SVGs. Eine Direktive wie `img-src 'self'` könnte verhindern, dass das SVG ein externes Bild lädt, das über `<image href="https://external-domain.com/...">` referenziert wird. Die gute Nachricht? Der Browser wird dir genau sagen, was falsch ist. Öffne die Entwicklerkonsole des Browsers (den Tab „Konsole“, nicht „Netzwerk“) und suche nach roten Fehlermeldungen. CSP-Verletzungen sind sehr explizit und geben an, welche Ressource blockiert wurde und welche Policy-Direktive dafür verantwortlich war, z. B.: „Refused to load the script because it violates the following Content Security Policy directive: script-src self.“ Wie du dies behebst, hängt von den Anforderungen deines SVGs ab. Du könntest `'unsafe-inline'` zu deiner `style-src`-Direktive hinzufügen, aber dies schwächt deine Sicherheitspolitik, daher würde ich dringend davon abraten. Eine viel bessere Lösung für animierte SVGs ist es, das CSS in ein externes Stylesheet zu verschieben und es mit `<?xml-stylesheet type="text/css" href="styles.css"?>` zu verknüpfen. Für `<use>`-Elemente, die auf externe Dateien verweisen, musst du entweder die Symbole inline einbetten oder deine `img-src`-Policy anpassen, um den Ursprung auf die Whitelist zu setzen. SVGs, die von CocoConvert oder ähnlichen Tools generiert werden, enthalten keine Skripte, daher wirst du bei ihnen keine `script-src`-Konflikte sehen. `style-src`-Konflikte sind jedoch weiterhin möglich, wenn das konvertierte SVG Inline-CSS für Farben oder Schriftarten verwendet.
Fehlkonfigurationen von Viewport und ViewBox, die SVG unsichtbar machen
Dies ist die ärgerlichste Art von SVG-Problem. Der Browser rendert das SVG perfekt, aber es wird mit Nullgröße oder irgendwo außerhalb des Bildschirms gerendert. Du siehst kein defektes Bildsymbol; du siehst nichts. Jeder, der schon einmal in den DevTools auf einen leeren Bereich gestarrt hat, das `<svg>`-Element direkt dort gesehen, aber nichts auf dem Bildschirm, kennt diesen besonderen Schmerz. Der Schlüssel ist die Beziehung zwischen dem `viewBox`-Attribut, das das interne Koordinatensystem der Grafik definiert, und den `width`- und `height`-Attributen, die definieren, wie viel Platz das SVG auf der Seite einnimmt. Wenn diese fehlen oder nicht übereinstimmen, bricht Chaos aus. Du wirst dies oft bei Figma-Exports sehen: Einem SVG wird `width="100%"` und `height="100%"` gegeben, aber es hat keine `viewBox`. Wenn du dieses SVG in einen Container legst, der keine explizite Höhe hat, kollabiert das SVG auf Nullhöhe. Die Lösung besteht darin, eine `viewBox` hinzuzufügen, die den ursprünglichen Artboard-Dimensionen entspricht (z. B. `viewBox="0 0 800 600"`), oder dem enthaltenden Element eine Höhe in deinem CSS zu geben. Ein weiterer Klassiker ist ein SVG, bei dem die Pfaddaten an Koordinaten weit außerhalb der `viewBox` gezeichnet werden. Wenn deine `viewBox` `"0 0 100 100"` ist, aber deine Pfaddaten bei `M 500 500` beginnen, wird die Grafik 400 Einheiten außerhalb des Bildschirms gezeichnet. Dies geschieht, wenn du Formen in einem Design-Tool verschiebst, ohne den Ursprung des Artboards zurückzusetzen. Um dies zu beheben, gehe zurück zu deinem Design-Tool, wähle alle Objekte aus und verwende einen Befehl wie „Begrenzungsrahmen zurücksetzen“ oder Ähnliches, und exportiere dann erneut. Um dies zu diagnostizieren, inspiziere das SVG in den DevTools. Wenn seine berechnete Breite oder Höhe 0 ist, ist die Größe der Übeltäter. Du kannst das Problem auch erzwingen, indem du temporär `style="border: 1px solid red; width: 200px; height: 200px;"` direkt zum `<svg>`-Tag hinzufügst. Dies erstellt ein sichtbares Feld und zeigt, ob ein Teil deiner Grafik erscheint.
Ladefehler bei Schriftarten und externen Ressourcen innerhalb von SVG
Ein SVG ist nicht immer in sich abgeschlossen. Es kann auf externe Ressourcen wie Schriftarten, Bilder, Farbverläufe und Filter verweisen. Wenn diese externen Aufrufe fehlschlagen, wird das SVG möglicherweise nur teilweise gerendert oder sieht völlig falsch aus, je nachdem, wie kritisch das fehlende Element ist. Schriftartfehler sind ein häufiges Ärgernis. Ein SVG, das eine benutzerdefinierte Schriftart in einem `<text>`-Element angibt, greift auf eine Systemstandardschriftart zurück, wenn diese Schriftart nicht verfügbar ist. Dies unterbricht das Rendering normalerweise nicht vollständig, kann aber dazu führen, dass Text über seinen Container hinausragt und das gesamte Layout durcheinanderbringt. Mein Rat: Konvertiere Text immer in Pfade (Outlines), bevor du ein SVG für die Webnutzung exportierst. In Illustrator ist das „Schrift > In Pfade umwandeln“; in Inkscape ist es „Pfad > Objekt in Pfad umwandeln“. Dies eliminiert die Schriftabhängigkeit und eine ganze Klasse von Problemen vollständig. Externe Bilder innerhalb eines SVGs sind noch heikler. Ein `<image>`-Tag, das auf eine URL verweist, kann fehlschlagen, weil die URL nicht erreichbar ist, weil der Bildserver keine ordnungsgemäßen CORS-Header hat oder weil eine CSP den Ursprung blockiert. Der Browser zeigt kein Fehlersymbol an; er rendert einfach einen leeren Bereich, wo das Bild sein sollte. Überprüfe deinen „Netzwerk“-Tab auf Anfragen mit dem Status 404 oder dem Status 0, was oft auf einen CORS- oder CSP-Block hinweist. Wenn du eine PDF- oder AI-Datei konvertierst, die Rasterbilder enthält, bettet CocoConvert diese Bilder direkt als Base64-Daten-URIs in das SVG ein. Dies löst das Problem der externen Referenzen, kann aber die SVG-Datei riesig machen. Ein PDF mit ein paar Fotos kann leicht zu einem über 5 MB großen SVG werden. In diesen Fällen sagen wir es ganz klar: Die Umwandlung in PNG oder WebP ist die praktischere Wahl. Wir werden nicht so tun, als wäre SVG immer die richtige Antwort.
Wenn die Konvertierung die Ursache des Problems ist (und was du dagegen tun kannst)
Manchmal liegt das Problem nicht bei deinem Browser oder deinem Server. Die SVG-Datei selbst war von Anfang an fehlerhaft, ein Opfer eines schlechten Konvertierungsprozesses. Es ist wichtig, diese Möglichkeit zu erkennen, denn das bedeutet, dass du aufhören solltest, deine Umgebung zu debuggen, und anfangen solltest, die Datei genau zu prüfen. Häufige Konvertierungsartefakte umfassen Pfaddaten mit absurd hoher Präzision (15+ Dezimalstellen), was Dateien aufbläht und Parser zum Timeout bringen kann; falsche Farbraumkonvertierungen von CMYK zu nicht unterstützten RGB-Werten; und fehlerhafte Textkodierung, wenn eine Quelldatei nicht-lateinische Skripte verwendete. Möglicherweise siehst du auch fehlende Namespace-Deklarationen bei der Konvertierung von Formaten, die auf proprietäres XML angewiesen sind. Wenn du eine schlechte Konvertierung vermutest, ist der schnellste Weg zur Überprüfung, das SVG in Inkscape zu öffnen. Es ist kostenlos, plattformübergreifend und hat einen sehr nachsichtigen SVG-Parser. Wenn die Datei in Inkscape korrekt aussieht, aber in Chrome fehlerhaft ist, liegt das Problem wahrscheinlich browserspezifisch. Wenn sie auch in Inkscape fehlerhaft ist, dann ist der Konvertierungsprozess selbst fehlgeschlagen und die Ausgabe ist beschädigt. CocoConvert verwendet robuste Konvertierungsbibliotheken, aber kein automatisiertes Tool ist perfekt. Eine hochkomplexe AI-Datei mit Hunderten von Ebenen oder ein PDF, das stark auf Transparenzeffekte angewiesen ist, kann eine unvollkommene SVG-Ausgabe erzeugen. In diesen Situationen ist der zuverlässigste Weg oft, die Quelldatei in ihrer ursprünglichen Anwendung zu öffnen, direkt in SVG zu exportieren und CocoConvert für Formatpaare zu verwenden, in denen wir uns auszeichnen, wie die Konvertierung einfacher PNGs in SVG oder SVG in PDF für den Druck. Wenn du ein fehlerhaftes SVG aus einer Konvertierung erhältst, melde es bitte über das Feedback-Formular auf der Ergebnisseite und füge, wenn möglich, die Originaldatei bei. Spezifische Beispiele sind der Weg, wie wir die Konvertierungspipeline für alle verbessern, und wir nehmen diese Berichte ernst.