Wann sollte man ein Bild als Base64 inlinen?

Wenn das Bild winzig ist (unter ~2 KB), nur einmal genutzt wird und die zusätzliche HTTP-Anfrage einen messbaren Anteil am Seitengewicht hätte. Typische Fälle: ein SVG-Icon in einem CSS-Modul, ein einmaliges Hintergrundmuster in einer E-Mail-Vorlage, ein Inline-Logo für eine statische Doku-Seite.

Grosse Bilder. Alles über ~10 KB serviert man besser als separate Datei, weil (a) der Browser sie seitenübergreifend cachen kann, (b) Base64 ~33 % Overhead hinzufügt, und (c) Inline-Inhalt nicht lazy geladen werden kann. Marketing-Hero-Bilder und Produktfotos sind fast nie gute Base64-Kandidaten.

Wie hoch ist der Grössen-Overhead?

Etwa 4/3 (33 % mehr). 3 Binärbytes werden zu 4 Base64-Zeichen. Ein 12-KB-PNG wird also nach dem Encoding ~16 KB. Gzip holt davon auf der Leitung einen Teil zurück, aber nicht alles.

Bild zu Base64

Bild als Data URI (Base64) konvertieren - mit kopierbaren CSS- und HTML-Snippets. Oder Data URI einfügen für Vorschau.

Bild hier ablegen oder klicken zum Auswählen

PNG, JPG, WebP, AVIF, GIF, SVG, BMP

Zwei Richtungen in einem Tab. Encode: Bild ablegen, `data:image/...;base64,...` mit kopierbaren CSS- und HTML-Snippets erhalten. Decode: Data URI einfügen, anzeigen, als normales Bild herunterladen. Nichts verlässt den Browser.

So funktioniert's

Richtung wählen
Encode (Bild → Base64) oder Decode (Base64 → Bild) über den Tab-Wechsel.
Ablegen oder einfügen
Encode: ein PNG / JPG / WebP / SVG ziehen. Decode: einen `data:image/...`-Data-URI-String einfügen.
Benötigtes Snippet kopieren
Drei fertige Snippets: roher Data URI, CSS `background-image: url(...)`, HTML `<img src='...'>`.

Was ist das?

Base64 ist eine Textkodierung für Binärdaten - je 3 Bytes werden zu 4 ASCII-Zeichen aus `A-Za-z0-9+/`. Mit dem Präfix `data:image/png;base64,` (oder einem anderen MIME-Typ) ergibt sich ein Data URI: eine eigenständige Referenz auf ein Bild, die Browser, CSS-Engines und HTML-Parser inline auflösen. Der Kompromiss ist ein Grössenaufschlag von ~33 % im Tausch gegen die eingesparte HTTP-Anfrage.

Wann verwenden

Kleine SVG-Icons in ein CSS-Modul einbetten, ein einmaliges Hintergrundmuster in eine HTML-E-Mail aufnehmen, ein Logo in ein zur Build-Zeit erzeugtes PDF inlinen, Test-Fixtures bündeln, oder ein OG-Bild dynamisch erzeugen und als Data URI ausliefern. Überall, wo sonst eine zusätzliche HTTP-Anfrage für ein winziges Asset nötig wäre.

Häufige Fehler

Ein Marketing-Hero-Foto inlinen und die HTML-Parsing-Zeit ruinieren. Vergessen, die Zeichen `+`, `/` und `=` URL-zu-encodieren, wenn der Data URI in einer anderen URL steht. Einen Data URI ohne das Präfix `data:image/png;base64,` einfügen (Browser lehnen ihn ab). Und ein grosses Asset inlinen, das der Browser sonst seitenübergreifend cachen könnte.

FAQ

Wann sollte man ein Bild als Base64 inlinen?: Wenn das Bild winzig ist (unter ~2 KB), nur einmal genutzt wird und die zusätzliche HTTP-Anfrage einen messbaren Anteil am Seitengewicht hätte. Typische Fälle: ein SVG-Icon in einem CSS-Modul, ein einmaliges Hintergrundmuster in einer E-Mail-Vorlage, ein Inline-Logo für eine statische Doku-Seite.
Wann NICHT inlinen?: Grosse Bilder. Alles über ~10 KB serviert man besser als separate Datei, weil (a) der Browser sie seitenübergreifend cachen kann, (b) Base64 ~33 % Overhead hinzufügt, und (c) Inline-Inhalt nicht lazy geladen werden kann. Marketing-Hero-Bilder und Produktfotos sind fast nie gute Base64-Kandidaten.
Wie hoch ist der Grössen-Overhead?: Etwa 4/3 (33 % mehr). 3 Binärbytes werden zu 4 Base64-Zeichen. Ein 12-KB-PNG wird also nach dem Encoding ~16 KB. Gzip holt davon auf der Leitung einen Teil zurück, aber nicht alles.