🖼️ Bild zu Base64 Konverter

So wandeln Sie ein Bild online in Base64 um

Eine Base64-Daten-URI nimmt ein Bild, das normalerweise in einer eigenen Datei liegen würde, und faltet es in eine Textzeichenkette, klein genug, um in ein HTML-Attribut, eine CSS-Deklaration oder ein JSON-Feld zu passen. Statt dass Ihr Browser einen separaten Weg zum Server zurücklegt, um logo.png zu holen, reist das Bild direkt in dem Dokument mit, das es braucht. Dieser Konverter baut diese Zeichenkette vollständig auf Ihrem eigenen Gerät auf, sodass Sie in der Zeit eines Drag-and-Drops von der Bilddatei zum einfügbereiten Code kommen.

Der Ablauf ist bewusst kurz gehalten. Ziehen Sie eine PNG-, JPG-, SVG-, WebP- oder GIF-Datei in die Ablagefläche oben, oder klicken Sie darauf, um den gewohnten Dateiauswahldialog zu öffnen. Sobald der Browser die Datei eingelesen hat, erscheint eine Vorschau, und das Base64-Ausgabefeld füllt sich automatisch, ganz ohne separaten "Umwandeln"-Button und ohne Neuladen der Seite.

1. Bild auswählen. Ziehen Sie eine Datei von Ihrem Desktop oder Dateimanager in die Ablagefläche, oder klicken Sie darauf, um eine zu suchen. Alles, was Ihr Browser als Bild darstellen kann, kann er auch kodieren.
2. Automatisch dekodieren lassen. Das Werkzeug liest die rohen Bytes Ihrer Datei über die eingebaute FileReader-API des Browsers und kodiert sie in dem Moment, in dem die Datei geladen ist, zu einer Base64-Zeichenkette.
3. Ausgabeformat wählen. Nutzen Sie das Dropdown-Menü Ausgabeformat, um zwischen einer reinen Daten-URI-Zeichenkette, einer fertigen CSS-background-image-Deklaration oder einem vollständigen HTML-img-Tag zu wechseln.
4. Ergebnis kopieren oder herunterladen. Klicken Sie auf Code kopieren, um den exakten Text in Ihre Zwischenablage zu holen, oder auf Text herunterladen, wenn die Zeichenkette lang ist und Sie sie lieber als Datei speichern möchten, um sie später zu verwenden.

Da der gesamte Vorgang als JavaScript direkt in Ihrem eigenen Browser-Tab läuft, gibt es keinen Upload-Schritt, keine Warteschlange auf einem Server, und die einzige Grenze ist der Arbeitsspeicher Ihres eigenen Rechners.

Die Syntax von Daten-URIs verstehen

Jede Base64-Zeichenkette, die dieses Werkzeug erzeugt, folgt demselben Muster, das das Daten-URI-Schema vorgibt: data:[mime-typ];base64,[kodierte-daten]. Das Präfix data: teilt dem Browser mit, dass dies keine gewöhnliche URL ist, die irgendwohin verweist, sondern der Inhalt selbst, direkt eingebettet ankommt. Der MIME-Typ direkt danach, etwa image/png, image/jpeg, image/svg+xml oder image/webp, sagt dem Browser genau, wie er die folgenden Bytes interpretieren soll, damit er ein PNG als PNG und ein SVG als SVG darstellt, statt es aus einer Dateiendung zu erraten, die es gar nicht mehr gibt.

Die Kennzeichnung ;base64 gibt an, welche Kodierung für die Nutzdaten verwendet wird, und alles nach dem Komma ist das eigentliche Bild, übersetzt von rohem Binärcode in das 64-Zeichen-Alphabet aus Großbuchstaben, Kleinbuchstaben, Ziffern, Plus und Schrägstrich. Ein winziges 16-mal-16-Favicon erzeugt vielleicht nur eine Zeichenkette von wenigen hundert Zeichen, während sich eine detaillierte Fotografie über mehrere hunderttausend Zeichen erstrecken kann, alle auf einer einzigen, ununterbrochenen Zeile.

Dieses Werkzeug erkennt den MIME-Typ und übernimmt die Kodierung automatisch anhand der Datei, die Sie ablegen, sodass Sie dieses Präfix niemals von Hand schreiben müssen. Das Muster zu kennen hilft aber, wenn Sie herausfinden wollen, warum eine im falschen Kontext eingefügte Zeichenkette sich weigert, angezeigt zu werden.

Die 33 Prozent Mehrgewicht: Warum Base64 schwerer wiegt als die Originaldatei

Die Base64-Kodierung fasst die ursprünglichen Binärdaten in Blöcken von jeweils 3 Byte zusammen und bildet jeden Block auf 4 druckbare Textzeichen ab. Dieses Verhältnis von 3 zu 4 ist durch die Mathematik der Kodierung selbst festgelegt, nicht durch das Bildformat oder die Kompressionseinstellungen, und es bedeutet, dass jede Base64-Zeichenkette etwa 33 % größer ist als die Datei, aus der sie stammt, noch bevor eine zusätzliche Kompression wie gzip oder Brotli auf Serverseite dazukommt.

In der Praxis bedeutet das: Aus einem 60-KB-Icon werden nach der Kodierung fast 80 KB, und aus einem 300-KB-Foto werden über 400 KB. Bei einem einzelnen kleinen Icon bleibt dieser Unterschied für den Nutzer unsichtbar. Wiederholt über eine Seite voller eingebetteter Vorschaubilder, oder eingebettet in eine CSS-Datei, die bei jedem Seitenaufruf an jeden Besucher ausgeliefert wird, summiert sich dieser Mehraufwand zu einem Dokument, das echt schwerer ist, als dieselben Bilder als separate Dateien auszuliefern.

Es lohnt sich, sich daran zu erinnern, dass diese Aufblähung zur Datei hinzukommt, sie nicht ersetzt. Ein JPEG in Base64 umzuwandeln komprimiert es nicht weiter, es ändert nur, wie dieselben bereits komprimierten Bytes als Text dargestellt werden. Jede Bildoptimierung, etwa das Verkleinern eines Fotos oder die Umwandlung in ein Format wie WebP, sollte deshalb vor der Kodierung geschehen, niemals danach.

Wann das Einbetten eines Bildes hilft (und wann es der Performance schadet)

Jedes über <img src="..."> oder ein CSS-url(...) referenzierte Bild löst normalerweise eine eigene HTTP-Anfrage aus. Bei älteren HTTP/1.1-Verbindungen konnten Browser pro Domain nur eine Handvoll gleichzeitiger Verbindungen öffnen, eine Seite mit Dutzenden kleiner Icons litt deshalb tatsächlich unter diesem Anfrage-Overhead, und diese Icons als Base64-Zeichenketten einzubetten beseitigte diese zusätzlichen Umwege vollständig. Das ist das ursprüngliche Argument fürs Einbetten, und es gilt weiterhin für kleine, dekorative Grafiken, die nur einmal erscheinen und sich selten ändern.

Moderne HTTP/2- und HTTP/3-Verbindungen multiplexen viele Anfragen über eine einzige Verbindung, was das ursprüngliche Argument erheblich schwächt. Zehn kleine externe Dateien über HTTP/2 zu holen ist längst nicht mehr so teuer wie noch vor einem Jahrzehnt, während der 33-prozentige Größenaufschlag von Base64 nach wie vor besteht. Das verschiebt die Waagschale für die meisten Alltagsbilder wieder zurück zu verlinkten Dateien und hebt das Einbetten für Fälle auf, in denen selbst eine einzige zusätzliche Anfrage noch etwas ausmacht, etwa bei Hauptgrafiken oberhalb der Sichtgrenze, die in dem Moment erscheinen müssen, in dem das HTML verarbeitet wird, oder bei Ein-Datei-Werkzeugen, die sich auf keine zweite Netzwerkanfrage verlassen können.

Eine praktische Faustregel: Betten Sie das wirklich Kleine ein, Icons, Ladeanzeigen, winzige Logos, in der Regel unter 5 bis 10 KB, und verlinken Sie alles andere. Ein großes eingebettetes Bild verzögert außerdem, wann der Browser das Parsen des umgebenden HTML- oder CSS-Dokuments beendet, da er die gesamte kodierte Zeichenkette erst einlesen muss, bevor er weitermachen kann. Das kann den Moment nach hinten verschieben, an dem der Rest der Seite sichtbar wird.

Base64-Bilder in CSS verwenden

Der häufigste Einsatzort für ein Base64-Bild ist eine background-image-Deklaration in CSS, genau das, was das CSS-Ausgabeformat in diesem Werkzeug erzeugt. Wählen Sie dieses Format, wird Ihre kodierte Zeichenkette in background-image: url('data:image/png;base64,...'); verpackt, bereit zum direkten Einfügen in ein Stylesheet, einen <style>-Block oder ein Inline-style-Attribut.

Dieses Muster taucht ständig für kleine, wiederkehrende visuelle Details auf: eine dezente Rauschtextur hinter einer Karte, ein individuelles Icon anstelle des Standardaufzählungszeichens einer Liste, der markierte Zustand einer Checkbox oder eines Radiobuttons, oder ein dekoratives SVG-Trennzeichen zwischen zwei Abschnitten. Da das Bild direkt mit dem CSS mitreist, gibt es nichts Zusätzliches, das der Browser noch holen müsste, sobald das Stylesheet einmal geladen ist, was für Elemente wichtig ist, die in dem Moment erscheinen, in dem die Seite gerendert wird, noch bevor spät geladene Ressourcen überhaupt Zeit hatten anzukommen.

Der Preis dafür ist, dass CSS voller langer Base64-Zeichenketten spürbar schwerer zu lesen und zu pflegen wird, und dass dieses aufgeblähte Stylesheet vollständig heruntergeladen und verarbeitet werden muss, bevor der Browser irgendeinen der folgenden Stile anwenden kann. Base64-Bilder im CSS auf wirklich kleine Ressourcen zu beschränken und für alles Größere eine normale url('/bilder/foto.jpg')-Referenz zu verwenden, hält sowohl das Stylesheet als auch die Seite selbst schnell.

Base64-Bilder in HTML und die Realität von E-Mail-Vorlagen

Die Wahl des HTML-Ausgabeformats verpackt Ihre kodierte Zeichenkette in ein einsatzbereites Tag, <img src="data:image/png;base64,..." />, das genau wie ein normales Bild-Tag überall dort funktioniert, wo ein Browser HTML darstellt, einschließlich Einzelseiten-Berichten, exportierten Dokumenten und Offline-Werkzeugen, die als einzige, in sich geschlossene Datei ohne jegliche externe Ressourcen funktionieren müssen.

E-Mail ist der einzige Ort, an dem dieses Muster echte Vorsicht verdient. Gmail und Apple Mail stellen eingebettete Base64-Bilder in der Regel klaglos dar, aber die Desktop-Versionen von Outlook nutzen die Rendering-Engine von Word statt einer modernen Browser-Engine, und diese Engine entfernt Bilder mit Daten-URI häufig oder weigert sich schlicht, sie anzuzeigen. Eine Marketing-E-Mail, die auf eingebetteten Logos aufbaut, kann in einem privaten Gmail-Postfach perfekt aussehen und bei einem großen Teil der geschäftlichen Outlook-Nutzer nur ein defektes Bildsymbol zeigen. Für alles, was als Massen-E-Mail verschickt wird, bleibt ein normal gehostetes Bild mit einem gut formulierten alt-Attribut die verlässliche Standardlösung, und Base64 sollte man sich für HTML aufheben, dessen Darstellung man vollständig selbst kontrolliert, etwa eine Benachrichtigung innerhalb der eigenen App, ein exportiertes PDF oder eine druckbare Quittung.

Außerhalb der E-Mail ist genau diese in sich geschlossene Eigenschaft echt nützlich: Eine einzelne HTML-Datei, die ihr eigenes Logo und ihre Icons als Base64-Zeichenketten enthält, lässt sich als Anhang verschicken, direkt von einer lokalen Festplatte öffnen oder unbegrenzt archivieren, alles ohne einen einzigen kaputten Bildlink, weil es keine externe Datei gibt, die ein künftiges Verschieben oder Umbenennen kaputtmachen könnte.

SVG und Base64: Wann die Kodierung wirklich hilft

SVG nimmt in dieser ganzen Diskussion eine ungewöhnliche Stellung ein, weil eine SVG-Datei bereits reiner Text ist, keine Binärdaten. Das heißt, sie lässt sich in einem CSS-url() mit gewöhnlicher URL-Kodierung statt mit Base64 einbetten, und ein URL-kodiertes SVG ist häufig kleiner als dieselbe Datei, durch Base64 gejagt, weil die URL-Kodierung nur eine Handvoll Sonderzeichen maskiert, statt jedes Byte in einem 4-Zeichen-Alphabet neu auszudrücken.

Base64 verdient sich seinen Platz bei SVG dennoch in einigen konkreten Situationen. Es ist die einfachste Lösung, sobald der umgebende Kontext die Anführungszeichen, Rauten und spitzen Klammern nicht verträgt, die rohes oder URL-kodiertes SVG-Markup enthält, etwa innerhalb einer einzigen JSON-Zeichenkette, einer Datenbankspalte oder eines Werts einer benutzerdefinierten CSS-Eigenschaft, bei dem das Maskieren von Zeichen umständlich wird. Es funktioniert auch gut als <img src="data:image/svg+xml;base64,...">'-Attribut, und genau dieses Format erzeugt dieses Werkzeug automatisch, sobald Sie eine SVG-Datei ablegen und die HTML-Ausgabe wählen.

Was Base64 für SVG nicht leisten kann, ist der Erhalt seines größten Vorteils: das Styling in Echtzeit. Ein SVG, das direkt als Inline-<svg>-Markup in Ihr HTML eingefügt wird, kann seine Füllfarbe mit currentColor und CSS ändern, auf :hover reagieren und mit JavaScript manipuliert werden, nichts davon ist mehr möglich, sobald es zu einer undurchsichtigen Base64-Zeichenkette abgeflacht wurde. Brauchen Sie ein Icon, dessen Farbschema veränderbar bleiben soll, behalten Sie das SVG-Markup inline bei. Brauchen Sie eine portable, undurchsichtige Bildreferenz, ist die Kodierung nach Base64 die richtige Wahl, und dieses Werkzeug erledigt diese Umwandlung mit einem einzigen Ablegen.

Kompromisse beim Browser-Caching

Eine normale, per URL referenzierte Bilddatei erhält einen eigenen Eintrag im HTTP-Cache des Browsers, geregelt durch die Cache-Control-Header, die der Server sendet. Besuchen Sie zehn Seiten, die alle dasselbe /logo.png referenzieren, lädt der Browser diese Datei genau einmal herunter und verwendet die zwischengespeicherte Kopie auf jeder folgenden Seite wieder, so lange der Cache-Header es erlaubt, manchmal über Monate hinweg.

Ein Base64-Bild genießt dieses Privileg nicht. Da es innerhalb des übergeordneten HTML- oder CSS-Dokuments steckt statt als eigene Ressource zu existieren, wird es bei jedem Laden dieses übergeordneten Dokuments erneut heruntergeladen, geparst und dekodiert, selbst zwischen Seiten, die exakt dasselbe Bild wiederverwenden. Es gibt keinen separaten Cache-Eintrag, den der Browser wiederverwenden könnte, denn aus Sicht der Caching-Schicht existiert überhaupt keine eigenständige Ressource, sondern nur mehr Bytes innerhalb eines Dokuments, das ohnehin schon abgerufen werden musste.

Das ist das stärkste Argument gegen das Einbetten von allem, was auf einer Website mehr als einmal auftaucht. Ein gemeinsam genutztes Logo, ein wiederkehrendes Icon-Set oder ein sitegweit verwendetes Hintergrundmuster wird als verlinkte Datei mit langer Cache-Lebensdauer, einmal heruntergeladen und überall wiederverwendet, wesentlich besser bedient als durch eine Base64-Zeichenkette, die in jede Seite und jedes Stylesheet dupliziert wird, das sie braucht. Heben Sie sich das Einbetten für Bilder auf, die wirklich nur in einem einzigen Dokument vorkommen, wo es von vornherein niemanden gibt, mit dem man sich einen Cache-Eintrag teilen könnte.

Typische Anwendungsfälle für diesen Bild-zu-Base64-Konverter

Entwickler, die Single-Page-Anwendungen oder interne Dashboards bauen, nutzen Base64 für kleine Platzhaltergrafiken und Lade-Icons, die erscheinen müssen, bevor das eigentliche JavaScript-Bundle fertig heruntergeladen ist, denn eine eingebettete Daten-URI wird schon mit dem allerersten Byte HTML sofort dargestellt, ohne auf eine zweite Anfrage zu warten.

Wer Offline-Berichte, exportierte PDFs oder in einer einzigen HTML-Datei ausgelieferte Ergebnisse erzeugt, greift zu Base64, um ein Dokument wirklich in sich geschlossen zu halten, mit Logo, Diagrammen oder Grafiken direkt in der Datei eingebettet, damit nichts kaputtgeht, wenn diese Datei per E-Mail verschickt, archiviert oder Jahre später auf einem Rechner ohne Zugriff auf das ursprüngliche Bild-Hosting geöffnet wird.

Designerinnen und Frontend-Entwickler nutzen das CSS-Ausgabeformat ständig für kleine Oberflächendetails, individuelle Zustände von Checkboxen und Radiobuttons, dezente Hintergrundtexturen und Ersatz für Icon-Fonts, in Fällen, in denen die Ressource klein genug ist, dass der 33-prozentige Mehraufwand kaum ins Gewicht fällt, die eingesparte Anfrage aber den ersten sichtbaren Seiteninhalt tatsächlich beschleunigt.

Und weil die gesamte Umwandlung lokal abläuft, nutzen genau deshalb auch diejenigen dieses Werkzeug, die etwas Sensibles umwandeln müssen, einen unterschriebenen und eingescannten Vertrag, ein privates Ausweisfoto, einen Screenshot eines noch nicht veröffentlichten Produkts, weil es nie verlangt, dass irgendetwas das eigene Gerät verlässt.

Warum dieser Konverter vollständig in Ihrem Browser läuft

Viele "Bild in Base64 umwandeln"-Werkzeuge im Netz laden im Hintergrund alles, was Sie hineinziehen, still auf einen Server hoch, kodieren es dort und schicken die Zeichenkette zurück. Dieser Umweg bleibt unsichtbar, wenn Sie ein öffentliches Logo umwandeln, wird aber zu einer echten Sorge, sobald das Bild ein unterschriebenes Dokument, ein privates Foto, ein Screenshot mit vertraulichen Daten oder irgendein noch nicht veröffentlichtes Designmaterial ist, das Sie nicht, und sei es auch nur kurz, auf dem Server eines Fremden liegen sehen möchten.

Dieser Konverter macht diesen Umweg nicht mit. Er liest Ihre Datei über die im Browser eingebaute FileReader-API, kodiert die Bytes mit JavaScript, das auf Ihrem eigenen Gerät läuft, und zeigt das Ergebnis an, alles ohne dass eine einzige Netzwerkanfrage Ihr Bild irgendwohin trägt. Öffnen Sie während der Nutzung den Netzwerk-Tab Ihres Browsers, werden Sie Ihre Datei die Seite nicht verlassen sehen. Das bedeutet außerdem: keine serverseitig auferlegte Größenbeschränkung, keine Verarbeitungswarteschlange, und keine Abhängigkeit davon, dass eine fremde API online bleibt; die Umwandlung ist genau so schnell und genau so verfügbar wie Ihr eigener Rechner.

Für Teams, die mit Kundenmaterial, einer noch in Entwicklung befindlichen Markenidentität oder allem umgehen, was einer Geheimhaltungsvereinbarung unterliegt, nimmt ein rein clientseitiges Werkzeug die Vertrauensfrage vollständig aus der Gleichung, statt Sie eine Datenschutzerklärung lesen und hoffen zu lassen. Es ist dieselbe Überlegung, die Entwickler dazu bringt, einen Formatierer oder Linter lieber lokal auszuführen, statt proprietären Quellcode in ein beliebiges Webformular zu kopieren.

Häufig gestellte Fragen

Verwandte Entwickler-Werkzeuge

🔒 100% Clientseitige Privatsphäre

Jedes Bild wird <strong>vollständig in Ihrem Browser</strong> dekodiert und kodiert. Es wird nichts auf einen Server hochgeladen. Ihr Bild bleibt auf Ihrem Gerät.