Bild zu Base64 und Data-URIs: Wann Bilder inline einbetten (2026)

Wenn Sie ein Bild in Base64 umwandeln, erhalten Sie eine Data-URI, also eine Zeichenkette wie data:image/png;base64,iVBORw0KGgo…, die Sie direkt in ein HTML-src oder ein CSS-url() einfügen können. Der Browser dekodiert sie an Ort und Stelle und zeigt das Bild ohne separaten Download an. Keine Datei zum Hosten, keine zusätzliche Anfrage.

Sollten Sie das also tun? Hier ist die kurze Regel. Betten Sie ein Bild als Base64 ein, wenn es klein (unter etwa 2 KB) ist, sich selten ändert und Sie eine HTTP-Anfrage einsparen wollen. Denken Sie an winzige Icons und Logos. Für alles andere behalten Sie es als normale Bilddatei: große Bilder, alles, was über mehrere Seiten hinweg wiederverwendet wird, alles, was der Browser zwischenspeichern soll. Der Haken ist, dass Base64 eine Datei rund 33 % größer macht, und sobald dieser Text in Ihrem HTML oder CSS steckt, lässt er sich nicht mehr eigenständig zwischenspeichern.

Wenn Sie die genauen Zahlen für eine bestimmte Datei wollen, übernimmt der Bild-zu-Base64-Konverter die Kodierung direkt in Ihrem Browser und zeigt den exakten Größenzuwachs an, sodass Sie mit echten Daten statt mit einer Faustregel entscheiden können. Dieser Leitfaden erklärt, was diese Data-URI eigentlich ist, woher die Größensteuer rechnerisch kommt, wann sich das Einbetten laut Entscheidungsmatrix lohnt und wann eine schlichte Datei gewinnt.

Was „Bild zu Base64” tatsächlich erzeugt: die Data-URI

Ein Bild in Base64 umzuwandeln liefert Ihnen keine Datei. Es liefert eine lange Zeichenkette, die dem in RFC 2397 definierten Data-URI-Format folgt (siehe MDNs data:-URL-Referenz). Die Zeichenkette besteht aus drei Teilen:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data:   MIME type  marker   the encoded image bytes

Der MIME-Typ teilt dem Browser mit, welche Art von Bild er dekodiert. Gängig sind image/png, image/jpeg, image/gif, image/webp, image/svg+xml sowie image/x-icon für Favicons. Der Marker ;base64, besagt, dass die folgenden Nutzdaten Base64 statt reiner Text sind. Alles nach dem Komma ist das Bild, neu ausgedrückt als druckbares ASCII.

Dieser letzte Teil ist für den Datenschutz wichtig. Die Umwandlung läuft vollständig in Ihrem Browser über die readAsDataURL-Methode der FileReader-API, und nichts wird auf einen Server hochgeladen. Sie können einen Screenshot vor dem Launch, ein internes Diagramm oder unveröffentlichte Grafiken in das Tool ziehen und dabei zusehen, wie der Netzwerk-Tab leer bleibt. Wie aus rohen Bytes diese ASCII-Zeichenkette wird, erklärt Base64 verstehen von Grund auf, und der vollständige Base64-Leitfaden überträgt dieselbe Data-URL-Idee auf Schriftarten, PDFs und andere Dateitypen.

Ein echtes Beispiel: ein 68 Byte großes transparentes PNG

Hier ist der kleinste praktische Fall, ein transparentes 1×1-PNG mit 68 Byte auf der Festplatte, als vollständige Data-URI:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==

Fügen Sie das in die Adressleiste eines Browsers ein, und Sie sehen ein gültiges Bild rendern, ganz ohne Netzwerkaktivität (nun ja, sehen ist relativ, denn es ist transparent). Beachten Sie die abschließenden ==: das ist Padding, auf das wir noch zu sprechen kommen. Genau so sieht auch Text-Base64 aus, nur angewendet auf Bild-Bytes statt auf Text. Wenn Sie lediglich reine Textzeichenketten kodieren oder dekodieren müssen, erledigt das Tool Base64 kodieren/dekodieren diesen Fall.

Die 33-%-Größensteuer (und warum sie sich aufsummiert)

Base64 arbeitet in festen Gruppen: aus jeweils 3 Byte Binärdaten werden 4 ASCII-Zeichen. Vier Drittel ergeben grob 1,33, woraus sich die Angabe +33 % ableitet. Mit einem oder zwei Byte Padding plus dem Präfix data:image/png;base64, ist der Mehraufwand bei winzigen Dateien etwas höher. Ein konkretes Beispiel: Aus einem 9 KB großen PNG werden rund 12 KB Text.

Warum genau 3 zu 4? Base64 verwendet ein Alphabet aus 64 Zeichen, nämlich A–Z, a–z, 0–9 sowie + und /. Vierundsechzig Symbole entsprechen 6 Bit Information pro Zeichen. Binäre Bytes haben jeweils 8 Bit. Das kleinste gemeinsame Vielfache von 6 und 8 ist 24 Bit, also 3 Byte beziehungsweise 4 Base64-Zeichen, weshalb der Encoder das Bild in 24-Bit-Schritten durchläuft. Wenn die Bildlänge kein sauberes Vielfaches von 3 ist, füllen ein oder zwei =-Zeichen die letzte Gruppe auf. Das ist die Mathematik, und sie ist fest. Es gibt keine Encoder-Einstellung, die die 33 % verringert.

Diese 33 % sind die sichtbaren Kosten. Die versteckten Kosten bestehen darin, dass sie sich aufsummieren, und genau diesen Teil überspringen die meisten „einfach einbetten”-Ratschläge:

• Das Bild wird jedes Mal neu heruntergeladen, wenn sich die enthaltende Datei ändert. Ein externes logo.png ist eine eigene Ressource. Betten Sie es in styles.css ein, und schon macht jede Bearbeitung dieses Stylesheets (eine Farbanpassung, eine neue Regel) auch den Cache für das Bild ungültig. Besucher laden das Bild, das sie bereits hatten, erneut herunter.
• Es kann nicht unabhängig zwischengespeichert werden. Eine normale Bilddatei wird einmal abgerufen und über jede Seite und jeden Besuch hinweg wiederverwendet. Eine eingebettete Data-URI ist Teil des Dokuments und wird daher auf jeder Seite, die sie einbettet, und bei jedem Cache-Miss dieses Dokuments erneut ausgeliefert.
• CSS blockiert das Rendering. Der Browser zeichnet nichts, bevor er das CSS hat. Stopfen Sie eine große Data-URI in ein Stylesheet, haben Sie eine renderblockierende Ressource vergrößert und verzögern den ersten Bildaufbau für die gesamte Seite.

Heben gzip oder brotli die 33 % auf?

Teilweise, nicht vollständig. Base64-Text ist repetitiv genug, dass gzip und brotli ihn gut komprimieren und einen guten Teil der Aufblähung über die Leitung zurückholen. Aber zwei Dinge bleiben wahr. Erstens ist das komprimierte Base64 meist immer noch etwas größer als das komprimierte Original-Binärformat, weil Sie dem Kompressor einen weniger effizienten Ausgangspunkt übergeben haben. Zweitens, und das wiegt schwerer, ändert Kompression nichts am Caching oder am Render-Blocking. Eine über die Leitung kleinere Data-URI wird trotzdem mit ihrer Host-Datei erneut heruntergeladen und kann trotzdem nicht eigenständig zwischengespeichert werden.

Kompression beseitigt also nicht die Einbettungskosten. Falls der Unterschied zwischen Minifizieren, Gzipping und Brotli unscharf ist, legt der Leitfaden zur Code-Minifizierung dar, wie sich diese Schichten stapeln und warum das Zusammenpressen der Bytes das durch Einbetten entstandene Caching-Problem nie löst.

Wann ein Base64-Bild sinnvoll ist (die Entscheidungsmatrix)

Die gesamte Entscheidung läuft auf eine Handvoll Faktoren hinaus. Hier stehen sie nebeneinander:

Faktor	Eher einbetten (Base64)	Eher eine normale Datei
Größe	Unter ~2 KB (grün)	Über ~10 KB (rot); 2–10 KB ist Ermessenssache (gelb)
Wiederverwendung	Eine Seite, eine oder zwei Stellen	Über viele Seiten hinweg wiederholt
Änderungshäufigkeit	Ändert sich fast nie	Wird oft bearbeitet
Kontext	HTML-E-Mail, in sich geschlossenes Widget oder Bookmarklet, JSON-/API-Nutzdaten, ein kritisches Icon above the fold, für das sich eine eingesparte Anfrage lohnt	Inhaltsbilder, geteilte, zwischenspeicherbare Assets

Diese Größenschwellen sind nicht willkürlich. Sie spiegeln das Ampel-Badge wider, das in den Bild-zu-Base64-Konverter eingebaut ist: grün unter 2 KB, gelb bis 10 KB, rot darüber. Das Tool liest Ihre tatsächliche Datei und sagt Ihnen, in welche Kategorie sie fällt.

Eine einfache Faustregel

Wenn Sie sich eine Zeile merken, dann diese: Unter ~2 KB und nur an einer oder zwei Stellen verwendet, lohnt sich Einbetten meist; über ~10 KB oder über mehrere Seiten hinweg wiederverwendet, gewinnt fast immer eine normale, zwischengespeicherte Datei. Der Mittelbereich von 2–10 KB ist der Punkt, an dem Sie die eingesparte Anfrage gegen den verlorenen Cache für Ihre konkrete Situation abwägen.

Gute Anwendungsfälle im Detail

Einige Fälle, in denen Base64 seinen Platz wirklich verdient:

• HTML-E-Mail. Viele E-Mail-Clients blockieren extern gehostete Bilder standardmäßig aus Datenschutzgründen, was jedes Layout kaputtmacht, das von einem entfernten Logo abhängt. Eine kleine eingebettete Data-URI rendert sofort, ohne Server-Abruf. Beschränken Sie das auf Logos und Icons; betten Sie niemals ein Foto in eine E-Mail ein.
• In sich geschlossene Widgets und Bookmarklets. Ein Bookmarklet oder ein einbettbares Widget muss ohne externe Abhängigkeiten funktionieren. Das Einbetten seiner Icons hält alles in einer einzigen, ablegbaren Datei.
• JSON- und API-Nutzdaten. Ein Thumbnail innerhalb eines JSON-Dokuments oder einer Konfigurationsdatei auszuliefern ist manchmal die sauberste Option: ein Roundtrip, ein Objekt, keine zweite Anfrage, die verdrahtet werden muss.
• Ein kritisches Icon above the fold. Wenn ein winziges Logo Teil Ihres Largest Contentful Paint ist und Sie eine Anfrage vom kritischen Pfad einsparen wollen, kann Einbetten helfen. Betonung auf winzig.

Ein Muster verbindet diese Fälle: Bei jedem reist das Asset zusammen mit etwas anderem und bräuchte sonst einen eigenen Auslieferungskanal. Eine E-Mail kann sich nicht auf Ihr CDN verlassen. Ein Bookmarklet hat keine zweite Datei zum Abrufen. Eine JSON-Antwort ist eine einzige Nutzlast. In jedem Fall ist die Alternative zum Einbetten nicht „eine zwischengespeicherte Datei”, sondern „ein fehlendes Bild”, was die Rechnung grundlegend verändert. Das ist der eigentliche Test für einen guten Base64-Anwendungsfall: nicht nur „ist es klein”, sondern „ist eine separate Datei hier überhaupt eine Option”.

Wann man nicht einbetten sollte: Caching, Lazy Loading und Core Web Vitals

Die Kehrseite ist länger, denn Einbetten deaktiviert stillschweigend mehrere Dinge, die der Browser gut beherrscht.

Sie verlieren unabhängiges Caching. Das schmerzt am meisten bei wiederkehrenden Besuchern. Ein normales Bild liegt nach dem ersten Besuch in deren Cache und lädt danach für immer sofort. Ein eingebettetes Bild hat keinen eigenen Cache-Eintrag, sondern reist jedes einzelne Mal mit dem Dokument mit, sodass ein wiederkehrender Besucher die Byte-Kosten immer wieder zahlt.

Sie verlieren Lazy Loading. Das Attribut loading="lazy" erlaubt es dem Browser, Bilder unterhalb des sichtbaren Bereichs aufzuschieben, bis der Nutzer in deren Nähe scrollt. Eine Data-URI wird in dem Moment geparst und „heruntergeladen”, in dem das HTML gelesen wird, sodass es nichts aufzuschieben gibt. Betten Sie ein Dutzend Bilder unterhalb des Folds ein, haben Sie sie alle in den initialen Ladevorgang gezwungen.

Sie vergrößern renderblockierende Ressourcen. Wie bereits erwähnt, bläht eine Data-URI im CSS eine Ressource auf, die den ersten Bildaufbau blockiert. Je größer dieses Stylesheet, desto länger bleibt die Seite leer.

Das Dekodieren ist auf Mobilgeräten teurer. Ein Data-URI wird bei jedem Laden seines Dokuments aus Base64 dekodiert, und auf schwächeren Smartphones summiert sich diese CPU-Arbeit; zudem landen die Bytes nie im Festplatten-Cache des Browsers, sodass ein schweres eingebettetes Bild bei jedem Besuch erneut dekodiert wird, statt wie eine normale Datei einmal gecacht und dekodiert zu werden.

Es gibt auch einen historischen Grund, warum sich dieser Ratschlag verschoben hat. Das ursprüngliche Argument für Einbetten, lautstark vertreten in der HTTP/1.1-Ära, war die Reduzierung von Anfragen: Jede Verbindung konnte jeweils nur eine Ressource abrufen, sodass eine Seite mit 40 kleinen Icons 40 Roundtrips bezahlte. HTTP/2 änderte das durch Multiplexing vieler Anfragen über eine einzige Verbindung, was zusätzliche kleine Dateien billig machte. Der große Vorteil des Einbettens, also weniger Anfragen, verflüchtigte sich damit weitgehend, während die Kosten blieben: verlorenes Caching, kein Lazy Loading, größere renderblockierende Dateien. Wenn Sie ältere Artikel lesen, die von Base64-Sprites begeistert sind, wägen Sie sie gegen das Protokoll ab, auf dem Ihre Website heute tatsächlich läuft.

Der Aspekt der Core Web Vitals

Einbetten wirkt in beide Richtungen auf LCP (Largest Contentful Paint). Bei einem kleinen Bild above the fold, das das LCP-Element ist, kann das Entfernen einer Anfrage den LCP etwas nach vorne ziehen. Betten Sie aber ein großes Bild ein, bewirken Sie das Gegenteil: Sie verzögern das Dokument oder Stylesheet, in dem es lebt, und schieben den LCP für die gesamte Seite nach hinten. Die Größenschwelle entscheidet, in welche Richtung es geht.

Für CLS (Cumulative Layout Shift) ändert Einbetten nichts an der Grundregel: Ein Bild braucht weiterhin explizite width und height (oder eine Aspect-Ratio-Box), damit der Browser Platz reservieren kann, bevor es rendert. Eine Data-URI ohne Maße verschiebt das Layout genauso wie ein entferntes Bild ohne Maße.

Ein besserer Hebel als Einbetten ist meist das Verkleinern der Quelle. Wenn Sie ein Bild vor dem Kodieren komprimieren, werden sowohl die Datei als auch jede daraus resultierende Data-URI kleiner. Der Leitfaden zur Bildkompression im Browser vs. Node erklärt, wie Sie das clientseitig oder in einem Build-Schritt tun, und WebP vs. AVIF vs. JPEG hilft Ihnen, ein Format zu wählen, das von vornherein klein ist.

Wie man Bilder in HTML, CSS, Markdown und JSON einbettet

Sobald Sie eine Data-URI haben, lesen Sie hier, wie sie in den jeweiligen Kontext eingefügt wird. Das sind die vier sofort einfügbaren Snippets, die der Bild-zu-Base64-Konverter für Sie erzeugt.

HTML. Fügen Sie die URI in ein beliebiges src ein:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">

CSS. Verpacken Sie sie in url() für ein background-image (das ist das kanonische Muster für ein Base64-Bild in CSS):

.icon {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}

Markdown. Ein in sich geschlossener Bildlink für READMEs, GitHub-Issues und Notebooks, wo Sie keine Datei hosten können:

![chart](data:image/jpeg;base64,/9j/4AAQSkZJRgABAQ…)

JSON. Ein eingebettetes Asset innerhalb einer API- oder Konfigurations-Nutzlast:

{ "icon": "data:image/png;base64,iVBORw0KGgo…" }

Alle vier funktionieren überall dort, wo eine URL akzeptiert wird: img src, CSS background, mask-image, sogar ein Favicon-<link>. Jeder moderne Browser unterstützt das data:-Schema.

Diese schnell erzeugen

Diese von Hand zu bauen ist fehleranfällig: Ein falscher MIME-Typ oder ein versehentlicher Zeilenumbruch, und das Bild rendert stillschweigend nicht. Ziehen Sie Ihre Datei in den Bild-zu-Base64-Konverter, und er erzeugt alle vier Snippets mit jeweils eigenen Kopier-Buttons, plus den exakten Größenzuwachs, sodass Sie von vornherein wissen, ob das Asset überhaupt inline gehört.

SVG: der Sonderfall, in dem Base64 meist verliert

SVG durchbricht die übliche Logik, weil SVG Text ist, nicht Binärdaten. Base64 existiert, um Binärdaten textsicher zu machen, aber SVG ist bereits XML-Text. Es als Base64 zu kodieren bläht nur eine Zeichenkette auf, die keine Kodierung brauchte, und macht sie dabei unlesbar. Für SVG im Speziellen ist Base64 daher fast immer die falsche Wahl.

Vergleichen Sie drei Wege, dasselbe Icon einzubetten:

/* 1. Base64-Data-URI — fügt die 33-%-Steuer zu Text hinzu, der sie nicht brauchte */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }

/* 2. URL-kodierte Data-URI — prozentkodiere eine Handvoll Zeichen, keine 33-%-Steuer */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }

/* 3. <svg> direkt im HTML inline — vollständig per CSS gestaltbar */

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
  <path d="M12 2 L22 22 H2 Z" fill="currentColor" />
</svg>

Option 2 (URL-Kodierung) ist meist kleiner als Option 1, bleibt menschenlesbar und komprimiert besser. Sie kodieren prozentual nur die Zeichen, die die URI kaputtmachen würden, also <, >, # und Anführungszeichen, und lassen den Rest lesbar. Der Ansatz des URL-Encoders/-Decoders ist im Tool selbst dokumentiert; greifen Sie nur dann zu Base64-SVG, wenn eine Build-Pipeline es ausdrücklich verlangt.

Warum ein inline <svg> oft ein Base64-PNG-Icon schlägt

Wenn Sie zwischen einem Base64-kodierten PNG-Icon und einem inline <svg> wählen, gewinnt das SVG meist in jeder Hinsicht. Es skaliert auf jede Größe ohne Unschärfe, trägt keine 33-%-Steuer und lässt sich, anders als jede Data-URI, per CSS gestalten, animieren und mit currentColor umfärben. Ein Base64-PNG ist ein Blob mit fester Auflösung, den Sie nach dem Kodieren nicht mehr anrühren können. Reservieren Sie Raster-Base64 für Fälle, in denen Sie wirklich ein Foto oder einen Raster-Screenshot inline brauchen.

Den anderen Weg dekodieren: Base64 zurück zum Bild

Das umgekehrte Problem ist genauso häufig: Sie haben eine Base64-Zeichenkette, gezogen aus einer API-Antwort, einer Logzeile, einer Datenbankspalte oder einem Stylesheet, das Sie debuggen, und müssen das tatsächliche Bild sehen.

Zwei Details bringen Leute ins Stolpern. Das erste ist rohes Base64 versus eine vollständige Data-URI. Eine vollständige Data-URI (data:image/png;base64,…) trägt ihren eigenen MIME-Typ; eine nackte Nutzlast (iVBORw0KGgo…) tut das nicht. Um eine nackte Nutzlast zu rendern, stellen Sie ihr entweder ein korrektes data:-Präfix voran oder lassen ein Tool das Format aus den führenden Bytes ableiten: iVBORw0KGgo bedeutet PNG, /9j/ bedeutet JPEG, R0lGOD bedeutet GIF.

Das zweite ist der Zeilenumbruch. Base64 aus E-Mails oder älteren Tools ist oft bei 76 Zeichen umbrochen, gemäß RFC 2045. Diese Zeilenumbrüche müssen vor dem Dekodieren entfernt werden, sonst ist die Zeichenkette in einem HTML-Attribut oder url() ungültig.

Im Browser können Sie eine vollständige Data-URI direkt an ein <img> übergeben:

<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">

Auf dem Server rekonstruiert Node die Datei aus der Nutzlast:

import { writeFileSync } from "node:fs";

const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // rohe Nutzlast, kein data:-Präfix
writeFileSync("output.png", Buffer.from(b64, "base64"));

Für einen Weg ohne Code nutzen Sie den Base64-zu-Bild-Konverter: Fügen Sie eine Zeichenkette ein (mit oder ohne Präfix, Zeilenumbrüche und alles), betrachten Sie eine Vorschau, lesen Sie ihre Maße und ihren MIME-Typ aus und laden Sie ein echtes PNG, JPG, GIF oder SVG herunter. Er entfernt Leerraum, toleriert ein fehlendes Präfix und erkennt das Format automatisch an den Magic Bytes.

Eine sinnvolle Plausibilitätsprüfung bei einem dekodierten Bild: Schauen Sie sich seine gemeldeten Maße an. Wenn Sie eine Zeichenkette aus einer Datei gezogen haben, die mehrere enthielt, und das Ergebnis 1×1 ist, haben Sie wahrscheinlich ein Tracking-Pixel statt des gewünschten Assets erwischt. Und denken Sie daran, dass das Dekodieren rein mechanisch und verlustfrei ist: Ein Base64-PNG kommt als exakt dasselbe PNG zurück, Byte für Byte, ohne Neukomprimierung. Das Einzige, was sich unterwegs geändert hat, war der Container, eine Textzeichenkette auf dem Hinweg, eine Binärdatei auf dem Rückweg.

FAQ

Soll ich meine Bilder in Base64 umwandeln?

Nur wenn es sich lohnt: kleine (unter ~2 KB), sich selten ändernde Icons oder Logos, bei denen das Einsparen einer HTTP-Anfrage zählt, plus HTML-E-Mail, in sich geschlossene Widgets und JSON-Nutzlasten. Große Bilder oder alles, was über mehrere Seiten hinweg wiederverwendet wird, sollte fast immer als normale Datei bleiben, damit Sie Caching und Lazy Loading behalten.

Wie viel größer macht Base64 ein Bild?

Etwa +33 %. Base64 kodiert jeweils 3 Byte Binärdaten als 4 ASCII-Zeichen, plus etwas Padding und das data:-Präfix. Aus einem 9 KB großen PNG werden rund 12 KB Text. Um ein Bild in Base64 umzuwandeln und den exakten Zuwachs für Ihre Datei zu sehen, meldet das Tool die genaue Zahl in seiner Metadaten-Leiste.

Lädt Base64 Bilder schneller?

Bei einem sehr kleinen Icon above the fold kann es das, indem es den Roundtrip einer Anfrage spart. Bei größeren oder wiederverwendeten Bildern ist es meist langsamer: Sie verlieren unabhängiges Caching, Sie können es nicht per Lazy Loading laden, und das Einbetten ins CSS vergrößert eine renderblockierende Ressource. Die Größe ist der entscheidende Faktor.

Kann ich ein Base64-Bild in CSS verwenden?

Ja: background-image: url("data:image/png;base64,…"). Für winzige Icons ist das in Ordnung. Denken Sie nur daran, dass die Data-URI Teil des Stylesheets wird, sodass die gesamte Datei jedes Mal neu heruntergeladen wird, wenn sich das CSS ändert, und das Bild nicht getrennt davon zwischengespeichert werden kann.

Soll ich SVG oder Base64 für Icons verwenden?

Bevorzugen Sie ein inline <svg> oder eine URL-kodierte SVG-Data-URI. SVG ist Text, skaliert sauber und trägt keine 33-%-Steuer, ist also meist kleiner als ein Base64-PNG, und Sie können es per CSS gestalten. Greifen Sie nur dann zu Base64, wenn Sie ausdrücklich ein Raster-Icon brauchen.

Wie wandle ich eine Base64-Zeichenkette zurück in ein Bild um?

Im Browser ziehen Sie eine vollständige data:image/…;base64,…-URI in ein <img src>. Auf einem Server verwenden Sie Buffer.from(b64, "base64"), um die Datei zu schreiben. Einer rohen Nutzlast muss ein data:-Präfix hinzugefügt werden, und bei zeilenumbrochenen Zeichenketten müssen zuerst die Zeilenumbrüche entfernt werden. Das Tool Base64 zu Bild erledigt das alles und lässt Sie das Ergebnis herunterladen.