Wann solltest du Base64-Bilder verwenden?

Die Faustregel

Bette ein Bild ein, wenn eine eigene Anfrage mehr kostet als die zusätzlichen Bytes. Mit modernen HTTP/2- und HTTP/3-Verbindungen sind zusätzliche Anfragen günstig, dieser Punkt ist also schnell erreicht: Eine gute Arbeitsgrenze liegt bei 2 bis 4 KB pro Bild. Verbreitete Build-Tools sehen das ähnlich: Vite bettet Assets unter 4 KB standardmäßig ein, die Asset-Module von webpack alles unter 8 KB.

Das Tool unten wandelt ein PNG (oder jedes andere Bild) in eine Data URI um. Leg das Bild ab oder öffne es und wähl dann unter Kopieren als, wie du es kopieren willst: Data URI, reines Base64, eine fertige CSS-Zeile mit background-image, ein HTML-img-Tag mit Breite und Höhe oder Markdown. Es zeigt die Größe der Data URI und wie viel größer sie als die Datei ist, und warnt dich, wenn das Ergebnis groß genug ist, um eine Seite zu bremsen. Die Bilder werden in deinem Browser umgewandelt und nie hochgeladen.

Was passiert, wenn du ein Bild einbettest

Eine Data URI wie data:image/png;base64,iVBORw0KGgo... steckt die Bytes des Bildes direkt in das HTML, CSS oder JSON, das es verwendet. Der Browser bekommt das Bild zusammen mit dieser Datei, ohne separaten Download. Das ist der ganze Vorteil. Die Nachteile kommen aus derselben Tatsache:

• Größe: Base64 schreibt 3 Bytes als 4 Zeichen, das Bild wächst also um etwa ein Drittel. Gzip- oder Brotli-Komprimierung auf dem Server holt bei der Übertragung einen Teil davon zurück, aber nicht alles, und bei schon komprimierten Bildern (PNG, JPG, WebP) bringt sie wenig.
• Caching: Eine separate Bilddatei landet einmal im Cache und wird auf jeder Seite wiederverwendet. Ein eingebettetes Bild wird nur als Teil der Datei gecacht, in der es steckt. Änderst du eine Zeile CSS, werden alle eingebetteten Icons neu heruntergeladen.
• Blockiertes Rendern: CSS blockiert die erste Darstellung. Jedes Kilobyte Bild, das in einem Stylesheet steckt, verzögert den Moment, in dem überhaupt etwas auf dem Bildschirm erscheint, auch wenn das Bild weit unten auf der Seite steht.
• Kein Lazy Loading: loading="lazy" und die Auswahl über srcset verlieren ihren Sinn, weil die Bytes schon mit der Seite angekommen sind.
• Wartung: Ein langer Base64-String ist im Code-Review unlesbar und durch einen fehlerhaften Kopiervorgang schnell kaputt.

Größentabelle: einbetten oder separate Datei?

Gute Einsatzbereiche für Base64-Bilder

• Kleine Icons in CSS, etwa Pfeile, Häkchen, eine eigene Checkbox oder der Pfeil eines Auswahlfelds, die zusammen mit den Styles erscheinen müssen und nie verspätet aufblitzen dürfen.
• Lieferungen aus einer einzigen Datei: ein HTML-Bericht, eine exportierte Rechnung, eine Dokumentationsseite oder ein Prototyp, der auch direkt von der Festplatte geöffnet oder als ein einziger Anhang verschickt funktionieren muss.
• APIs und Datenbanken: JSON kennt keinen Binärtyp, deshalb werden Bilder in API-Anfragen und Antworten (Unterschriften, Profilbilder, gescannte Dokumente, in manchen Integrationen auch Produktbilder für Marktplätze) üblicherweise als Base64-String verschickt.
• Platzhalter in niedriger Qualität: Eine winzige, unscharfe Version direkt im HTML erscheint sofort, während das volle Bild lädt.
• SVG-Icons: SVG ist Text und braucht oft gar kein Base64. Mit der Option URL-Kodierung statt Base64 (kürzer) im Tool bleibt das SVG lesbar, und das Ergebnis ist meist kürzer.

Wann du darauf verzichten solltest

• Fotos und jedes Bild über etwa 10 KB auf einer Webseite. Nimm eine normale Datei in WebP oder AVIF, mit gesetzter Breite und Höhe und Lazy Loading für Bilder unterhalb des sichtbaren Bereichs.
• Das größte Bild oben auf der Seite (das LCP-Element). Ein großes eingebettetes Bild macht das HTML selbst schwer und verzögert alles andere darin. Eine separate Datei mit Preload ist meist schneller.
• Bilder, die sich über viele Seiten wiederholen, etwa das Logo der Website oder ein Hintergrundmuster. Hier schlägt das Caching die gesparte Anfrage.
• HTML-E-Mails an ein breites Publikum. Viele E-Mail-Programme zeigen Data-URI-Bilder nicht an, am bekanntesten Gmail und Outlook für Windows. Nimm stattdessen gehostete Bilder oder Anhänge, die über eine Content-ID (CID) eingebunden werden. Eingebettete Data URIs funktionieren vor allem in Apple Mail und einigen mobilen Apps, und das reicht für einen Newsletter nicht.
• Sehr große Data URIs allgemein. Der alte Internet Explorer 8 begrenzte sie auf 32 KB. Moderne Browser akzeptieren viel größere, aber die Leistung leidet lange, bevor irgendeine Grenze erreicht ist.

So machst du es richtig

Verkleinere das Bild, bevor du es umwandelst. Jedes gesparte Byte wird in der Data URI mit 4/3 multipliziert. Komprimiere also PNG-Icons, verkleinere zu große Bilder auf die Größe, in der sie angezeigt werden, und nimm für Fotos, die unbedingt eingebettet werden müssen, etwa in JSON-Daten, ein JPG oder WebP mit vernünftiger Qualität. Die Tools Bild komprimieren und Bildgröße ändern auf dieser Website erledigen das im Browser, und die kleinere Datei kannst du dann hierher mitnehmen.

Gib die Abmessungen an. Ein img-Tag ohne width und height lässt das Layout springen, wenn das Bild erscheint. Die HTML-Ausgabe dieses Tools enthält deshalb die echte Breite und Höhe des Bildes.

Behalte die Quelldatei. Leg das originale PNG oder SVG in deinem Projekt ab und erzeuge die Data URI daraus, entweder mit deinem Build-Tool oder mit diesem Tool, wenn sich etwas ändert. Betrachte den Base64-String nie als Original.

Miss nach. Vergleiche die Seite mit und ohne eingebettete Bilder im Netzwerk-Tab der Entwicklertools deines Browsers oder mit Lighthouse. Wird die CSS- oder HTML-Datei spürbar größer, ohne dass etwas schneller wird, geh zurück zur separaten Datei.