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 Zeichen- oder Byte-Limit (z. B. VARCHAR(65535)) können Base64-Strings abschneiden. Ein 100-KB-PNG erzeugt ungefähr 136.000 Base64-Zeichen. Wird der Wert bei 65.535 Bytes abgeschnitten, ist das dekodierte Bild beschädigt. Lösung: Einen für Datenbank und Encoding ausreichend großen Typ wählen, etwa MEDIUMTEXT oder LONGTEXT in MySQL, und Abschneiden erkennen.

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

Padding-Zeichen wie = können bei URL- oder Formularparametern falsch verarbeitet werden; auch + kann als Leerzeichen ankommen. Lösung: den Wert vor der Übertragung URL-kodieren, bei Bedarf URL-sicheres Base64 verwenden und das Padding beim Empfang validieren.

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) kann ein Browser das Bild trotzdem rendern, aber das Ergebnis hängt vom jeweiligen Verbraucher ab. Strengere Clients oder serverseitige Konvertierung können an der Abweichung scheitern. Fazit: MIME und tatsächliche Bytes abgleichen; die Abweichung ist eine mögliche, nicht die universelle 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-Werte können beschädigt werden, wenn serialisiertes JSON oder URL-kodierte Daten als Rohtext behandelt werden. \/ ist nach korrektem JSON.parse() unproblematisch; bei Formularparametern kann + als Leerzeichen ankommen. Lösung: JSON parsen, URL-Werte kodieren und die dekodierten Bytes am Empfänger validieren.

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.