Base64-Bild wird nicht angezeigt? 10 häufige Ursachen und Lösungen

Sie haben ein Bild in Base64 kodiert, den Data-URI in Ihr HTML eingefügt und… nichts. Nur ein kaputtes Bild-Icon. Schlimmer noch: Es funktioniert in Chrome, aber nicht in Safari; lokal ist alles in Ordnung, in Produktion aber nicht.

Base64-Bildfehler sind frustrierend, weil der String auf den ersten Blick korrekt aussieht. Die wahre Ursache verbirgt sich meist in einem subtilen Detail: ein fehlendes Zeichen im Präfix, unsichtbare Leerzeichen beim Kopieren oder ein Backend, das Ihre Daten stillschweigend doppelt kodiert hat. Dieser Leitfaden deckt alle 10 häufigen Ursachen mit Codebeispielen und Lösungen ab.

Kurzreferenz: Symptom → Ursache → Lösung

Starten Sie hier. Finden Sie Ihr Symptom, identifizieren Sie die wahrscheinliche Ursache und springen Sie zur detaillierten Lösung weiter unten.

Präfix-Fehler: Der data:-URI ist fehlerhaft

Das data-URI-Schema hat eine strenge Syntax. Ein falsches Zeichen und der Browser behandelt Ihren Base64-String als defekte URL.

Ursache 1: Der gesamte data-URI-Präfix fehlt

Wenn Sie den Base64-String ohne data:image/...;base64,-Präfix direkt in src setzen, interpretiert der Browser ihn als relativen URL-Pfad – das Ergebnis ist ein 404.

❌ <img src="iVBORw0KGgo..." />
✅ <img src="data:image/png;base64,iVBORw0KGgo..." />

Ursache 2: Semikolon als Komma geschrieben

data:image/png,base64,... statt data:image/png;base64,... lässt den Browser base64,... als Klartext statt als Base64-Indikator behandeln.

❌ data:image/png,base64,iVBORw0KGgo...
✅ data:image/png;base64,iVBORw0KGgo...

Ursache 3: Fehlendes Komma nach "base64"

Das Komma zwischen base64 und den Daten ist Pflicht. Ohne es – data:image/png;base64iVBOR... – liest der Browser base64iVBOR... als Charset-Name.

❌ data:image/png;base64iVBORw0KGgo...
✅ data:image/png;base64,iVBORw0KGgo...

Encoding-Korruption: Der Base64-String selbst ist beschädigt

Selbst bei korrektem Präfix können die kodierten Daten bei Speicherung, Übertragung oder Kopieren stillschweigend beschädigt werden.

Ursache 4: String abgeschnitten

Datenbankspalten mit Zeichenlimit (z. B. VARCHAR(65535)) schneiden Base64-Strings stillschweigend ab. Ein 100-KB-PNG erzeugt ~136.000 Base64-Zeichen. Bei 65.535 abgeschnitten ist das dekodierte Bild vollständig kaputt. Lösung: TEXT oder LONGTEXT verwenden.

Ursache 5: Ungültige Zeichen (Leerzeichen, Sonderzeichen)

Gültiges Base64 enthält nur A-Z, a-z, 0-9, +, / und =. Beim Kopieren eingeschlichene Leerzeichen verursachen InvalidCharacterError bei atob(). Lösung: str.replace(/\s/g, '').

Ursache 6: Zeilenumbruch-Verschmutzung

openssl base64 fügt standardmäßig alle 76 Zeichen ein \n ein (RFC 2045). Diese Zeilenumbrüche zerstören Data-URIs in HTML. Lösung: openssl base64 -A oder Zeilenumbrüche entfernen: str.replace(/[\r\n]/g, '').

Ursache 7: Padding wird beim URL-Parsing entfernt

Die Padding-Zeichen = gehen bei URL-Parametern oft verloren (= ist reserviert). Manche Browser tolerieren fehlendes Padding, andere nicht. Lösung: Vor URL-Einbettung encodeURIComponent() verwenden oder empfangsseitig Padding ergänzen.

MIME-Typ falsch: Bricht es wirklich?

Überraschenderweise führt ein falscher MIME-Typ meist nicht dazu, dass das Bild nicht angezeigt wird.

Ursache 8: Deklarierter MIME stimmt nicht mit dem tatsächlichen Dateityp überein

Bei data:image/png;base64,/9j/4AAQ... (JPEG-Daten mit PNG-MIME) rendern die meisten Browser dank Content Sniffing korrekt. Problematisch wird es bei: (1) strengem CSP mit MIME-Erzwingung, (2) serverseitiger Formatkonvertierung basierend auf dem MIME. Fazit: Korrigieren, aber selten die wahre Ursache.

Pipeline-Fehler: Daten sind vor dem Browser bereits beschädigt

Am schwierigsten zu diagnostizieren: Der Base64-String sieht im Code korrekt aus – die Beschädigung passiert bei Serialisierung oder Übertragung.

Ursache 9: Doppelte Base64-Kodierung

Ein Backend, das bereits kodierte Daten erneut kodiert, erzeugt das Base64 eines Base64-Strings. ~33% länger als erwartet, einmaliges Dekodieren ergibt Text statt Binärdaten. Erkennung: Einmal dekodieren – sieht das Ergebnis wieder wie Base64 aus (Buchstaben + =), liegt Doppelkodierung vor. Lösung: Überflüssigen Kodierungsschritt im Backend entfernen.

Ursache 10: JSON-Escape- oder URL-Encoding-Verschmutzung

Base64 enthält /. Manche JSON-Serialisierer escapen dies als \/. Ohne JSON.parse beschädigen die zusätzlichen Backslashes die Daten. Bei URL-Parametern wird + zu Leerzeichen und = verschwindet. Lösung: JSON.parse() für JSON, encodeURIComponent() für URLs.

Systematische Debugging-Vorlage

Wenn keine der obigen Ursachen zutrifft, gehen Sie diese Schritte durch:

1. Data-URI in der Adressleiste testen — Fügen Sie den vollständigen data:image/...;base64,...-String direkt in die Adressleiste ein. Wird er angezeigt, liegt das Problem in der Art, wie Ihre Anwendung den String einfügt.
2. Browser-Konsole prüfen — F12 drücken und in der Console nach net::ERR_INVALID_URL oder CSP-Verletzungen suchen.
3. String-Länge vergleichen — Vergleichen Sie die Länge des Base64-Strings an der Quelle (Backend) mit dem, was im Frontend ankommt.
4. Dekodieren und untersuchen — atob() in der Konsole verwenden. Bei InvalidCharacterError enthält der String ungültige Zeichen.
5. Doppelkodierung erkennen — Einmal dekodieren. Sieht das Ergebnis wie Base64 aus, nochmals dekodieren. Ergeben sich Binärdaten, hat Ihre Pipeline einen überflüssigen Schritt.

Base64 sofort mit ViewJSON validieren

Statt Base64-Strings manuell zu prüfen, fügen Sie Ihr JSON in ViewJSON ein. Es erkennt Base64-Medien automatisch per Magic-Number-Erkennung und zeigt integrierte Vorschauen – erscheint die Vorschau, ist Ihr Base64 gültig.