Bild zu Base64 Konverter

So funktioniert es

1. Bild hierher ziehen oder auswählen. Der Browser liest die Datei lokal mit der FileReader-API. Es wird nichts irgendwohin hochgeladen.
2. Der Encoder wandelt die Bytes um mithilfe des Standard-Base64-Alphabets: Je 3 Eingabe-Bytes werden zu 4 ASCII-Zeichen aus A-Z a-z 0-9 + /, mit bis zu zwei nachgestellten =-Füllzeichen, wenn die Eingabelänge kein Vielfaches von 3 ist.
3. Kopieren Sie, was Sie brauchen. „Base64 kopieren“ liefert Ihnen nur die kodierte Zeichenkette (nützlich für JSON-Payloads oder die Backend-Verarbeitung). „Data-URI kopieren“ liefert Ihnen die vollständige Form data:image/png;base64,…, fertig zum Einfügen in ein <img src>-Attribut oder ein CSS-background-image: url(…).
4. Fügen Sie es dort ein, wo es hingehört. Die Ausgabe ist reiner Text, funktioniert in HTML, CSS, JSON, JavaScript, Markdown oder überall sonst, wo eine Zeichenkette leben kann.

Was Base64 wirklich macht

Base64 ist in RFC 4648 (Oktober 2006) definiert. Die Kodierung nimmt jeweils 24 Bit Eingabe (drei Bytes) und schreibt sie als vier 6-Bit-Indizes in ein 64-Zeichen-Alphabet um. Die Mathematik ist exakt: 3 Bytes (24 Bit) → 4 Zeichen (jedes trägt 6 Bit). Wenn die Eingabelänge kein Vielfaches von 3 ist, hängt der Encoder =-Füllzeichen an, damit die Ausgabelänge ein Vielfaches von 4 wird.

Zwei praktische Folgen:

• Die Ausgabe ist immer ~33 % größer als die Eingabe. Das Verhältnis 4/3 ist grundlegend für den Algorithmus. Ein 100 KB großes Bild wird zu ~133 KB Base64. Mit MIME-typischen Zeilenumbrüchen nach 76 Zeichen liegt der Overhead näher bei 37 %.
• Die Ausgabe ist überall textsicher. Das 64-Zeichen-Alphabet ist die Schnittmenge jedes gängigen ASCII-Textkanals, HTML, JSON, XML, E-Mail, URLs (mit der URL-sicheren Variante), Quellcode. Genau das ist der ganze Grund, warum Base64 existiert: um Binärdaten durch Systeme zu bewegen, die für Text ausgelegt wurden.

RFC 4648 §12 benennt eine wichtige Nicht-Eigenschaft ausdrücklich: „Die Base64-Kodierung verbirgt optisch ansonsten leicht erkennbare Informationen wie Passwörter, bietet aber keinerlei rechnerische Vertraulichkeit.“ Jeder kann eine Base64-Zeichenkette in zwei Codezeilen in jeder Sprache dekodieren. Es ist Kodierung, keine Verschlüsselung.

Data-URIs: die Inline-Bild-Form

Eine „Data-URI“ ist das Wrapper-Format, das eine Base64-Zeichenkette an die Stelle einer Bild-URL treten lässt. RFC 2397 (1998) definiert die Syntax:

data:[<mediatype>][;base64],<data>

Für Bilder bedeutet das data:image/png;base64,iVBORw0KGgo… in einem <img src>-Attribut oder background-image: url("data:image/svg+xml;utf8,<svg…>") in CSS. Das Token ;base64 sagt dem Browser, dass der Datenteil kodiert ist; ohne es werden die Daten als prozentkodierter Text aufgefasst. RFC 2397 selbst merkt an, dass Data-URIs „nur für kurze Werte nützlich“ sind, ein Hinweis, der zu einer harten Performance-Regel gereift ist.

Wann Sie ein Bild als Base64 einbetten sollten

• Einzeldatei-Artefakte. Eine E-Mail-Signatur mit eingebettetem Logo, das das Weiterleiten überstehen muss. Eine eigenständige HTML-Demo für CodePen, JSFiddle oder eine Fehlerbericht-Repro. Ein generiertes PDF, in das das Bild eingebettet sein muss, damit die Datei offline funktioniert.
• Winzige Icons auf dem kritischen Pfad. Ein 200-Byte-Chevron oder Lade-Spinner, eingebettet in kritisches CSS, lädt möglicherweise schneller, als eine separate HTTP-Anfrage auszulösen, besonders bei langsamen Verbindungen.
• Inline-JSON-/API-Antworten. Avatar-Uploads, Signaturen, OCR-Proben, generierte QR-Codes, alles, wo der API-Konsument die Bytes inline erwartet statt einer separaten abzurufenden URL.
• Sandboxed iframes oder andere Kontexte, die das Laden externer Ressourcen verbieten.
• Konfigurationsdateien, bei denen Sie keine begleitende Bilddatei neben der JSON-/TOML-/YAML-Datei haben möchten.

Wann Sie ein Bild nicht als Base64 einbetten sollten

Für die meisten Produktions-Websites ist ein eingebettetes Base64-Bild langsamer als eine normale <img>-Referenz. Fünf sich verstärkende Gründe:

1. 33 % Größen-Overhead, immer. Jedes Byte kostet nach der Kodierung 4/3 Byte. Sobald gzip angewendet wird, schrumpft der scheinbare Overhead (weil Base64 repetitiv ist), aber die Bytes, die der Browser parst, sind immer noch 33 % größer als das Original.
2. Das Bild kann nicht separat zwischengespeichert werden. Ein externes image.png wird einmal abgerufen und auf jeder Seite wiederverwendet, die darauf verweist. Ein Base64-Bild lebt innerhalb des HTML oder CSS und wird bei jeder Änderung dieser Datei erneut heruntergeladen.
3. Verlangsamt das Parsen von HTML und CSS. Lange eingebettete Zeichenketten in renderblockierendem CSS schieben den kritischen Pfad weiter hinaus. Harry Roberts (CSS Wizardry) maß ein echtes Kunden-Stylesheet mit 925 KB mit Base64-Bildern gegenüber 708 KB ohne und 232 KB gzippt gegenüber 68 KB. Das Entfernen von Base64 verringerte das gzippte CSS um 70,68 %.
4. Kann nicht per Lazy Loading geladen werden. Das Attribut loading="lazy" verzögert das Abrufen eines Bildes, bis der Nutzer in seine Nähe scrollt. Base64-Bilder sind bereits im Dokument, es gibt nichts zu verzögern.
5. HTTP/2 und HTTP/3 haben das Problem „zu viele Anfragen“ bereits gelöst. Multiplexing lässt eine einzelne Verbindung Hunderte von Dateien parallel ausliefern, sodass die ursprüngliche Rechtfertigung für das Einbetten größtenteils entfällt.

Eine praktische Faustregel von Googles PageSpeed und den meisten Performance-Autoren: Betten Sie nur ein, wenn das Bild kodiert unter ~1 bis 2 KB liegt, und nur, wenn es im sichtbaren Bereich in kritischem CSS erscheint. Alles Größere schneidet als separate Datei mit ziemlicher Sicherheit besser ab.

SVG: UTF-8-Kodierung verwenden, nicht Base64

SVG ist bereits Text, daher verschwendet das Kodieren als Base64 ~33 % der Bytes ohne Nutzen. Die kleinere Form ist URL-kodiertes UTF-8:

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

Die meisten modernen Build-Werkzeuge (PostCSS' postcss-inline-svg, Webpacks svg-url-loader) geben standardmäßig die URL-kodierte Form aus. Bevorzugen Sie für Inline-SVG diese Form gegenüber Base64, sofern nicht ein bestimmter Konsument ;base64 erfordert.

MIME-Typen, die dieses Werkzeug erkennt

Das Medientyp-Präfix der Data-URI ist das, was dem Konsumenten sagt, wie die Bytes zu interpretieren sind. Der Browser erkennt es aus der Datei, die Sie auswählen:

Hinweise zu Datenschutz und Sicherheit

Die meisten Online-Seiten für „Bild zu Base64“ laden Ihre Datei auf ihren Server hoch, kodieren dort und liefern das Ergebnis zurück. Das bedeutet, dass Screenshots von Vorab-UIs, NDA-geschützte Designs, Fotos von Kindern, medizinische Scans oder Unterschriften-auf-Verträgen die Infrastruktur eines Dritten durchlaufen. Dieses Werkzeug kodiert lokal, der FileReader des Browsers liest die Datei in den Speicher, der Encoder läuft in JavaScript auf Ihrem Gerät, und das Einzige, was die Seite verlässt, ist die kodierte Zeichenkette, wenn Sie sie kopieren.

Zwei Hinweise zur Content Security Policy, die man kennen sollte, wenn man Base64-Bilder in der Produktion ausliefert:

• Eingebettete Base64-Bilder umgehen img-src-Regeln, sofern Sie sie nicht ausdrücklich erlauben. Eine strenge CSP wie img-src 'self' blockiert data:-URIs. Um sie zu erlauben, schreiben Sie img-src 'self' data:.
• Dasselbe gilt für in CSS eingebettete Hintergrundbilder. Wenn eine CSP Ihre eingebetteten Hintergründe blockiert, prüfen Sie zuerst die img-src-Direktive.

Häufige Fehler

1. Base64 als Verschleierung behandeln. Das ist es nicht. Jeder kann es in zwei Zeilen jeder Sprache dekodieren. Stecken Sie keine Anmeldedaten, API-Schlüssel oder sensiblen Daten in Base64-Zeichenketten, „um sie zu verbergen“.
2. Ein 200 KB großes Hero-Bild einbetten. Das Bild wird kodiert zu 266 KB, steckt im HTML fest, kann nicht separat zwischengespeichert werden, kann nicht per Lazy Loading geladen werden, und das erste Rendern der Seite ist sichtbar langsamer. Liefern Sie es als normale Datei aus.
3. Das rohe Base64 kopieren, wenn Sie die Data-URI brauchten. Eine nackte Base64-Zeichenkette in einem <img src>-Attribut wird als defekt dargestellt, Sie brauchen das Präfix data:image/png;base64,. Verwenden Sie die Schaltfläche „Data-URI kopieren“.
4. SVG mit Base64 kodieren. SVG ist bereits Text. Kodieren Sie es stattdessen per URL und sparen Sie den Overhead von 33 %.
5. CSP vergessen. Strenges img-src 'self' blockiert Data-URIs. Fügen Sie der Direktive data: hinzu, wenn Sie Base64-Bilder ausliefern.
6. Versuchen, eine Base64-Zeichenkette mit vorangestelltem data:-Präfix zu dekodieren. Der Teil data:image/...;base64, ist Metadaten; entfernen Sie ihn, bevor Sie die Zeichenkette an einen Base64-Dekoder übergeben.
7. Vertrauliche Bilder in einen serverseitigen Encoder einfügen. Wenn die URL „encode“ sagt, der Netzwerk-Tab aber ein POST zeigt, hat Ihr Bild gerade Ihre Maschine verlassen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen „Base64“ und „Data-URI“?

Base64 ist die Kodierung (eine Zeichenkette wie iVBORw0KGgo…. Eine Data-URI ist der Wrapper, der eine Base64-Zeichenkette in etwas verwandelt, das für eine Bild-URL einstehen kann) data:image/png;base64,iVBORw0KGgo…. Der Wrapper sagt dem Browser den Medientyp und die Kodierung, sodass er weiß, wie er die Bytes interpretieren muss. Die zwei Schaltflächen in diesem Werkzeug liefern Ihnen jede Form separat.

Ist Base64 sicher?

Nein, und dafür ist es nicht gedacht. Base64 ist Kodierung, keine Verschlüsselung. RFC 4648 §12 sagt es direkt: Es „bietet keinerlei rechnerische Vertraulichkeit“. Jeder kann eine Base64-Zeichenkette sofort dekodieren. Wenn Sie Vertraulichkeit brauchen, verschlüsseln Sie die Daten zuerst (mit AES usw.) und kodieren Sie dann den Geheimtext für den Transport mit Base64.

Wie groß kann das Bild sein?

Das Werkzeug erlegt keine harte Grenze auf, da die Kodierung im Speicher Ihres Browsers geschieht. Die praktische Obergrenze ist das, was Ihr Gerät fassen kann, typischerweise sind Dutzende MB auf modernen Laptops in Ordnung. Die größere Einschränkung ist die Unterstützung beim Konsumenten: Viele E-Mail-Clients, Browser und APIs haben eigene Größenbegrenzungen für Data-URIs, und etwas über ein paar KB einzubetten ergibt für die Performance selten Sinn.

Warum ist meine Base64-Zeichenkette 33 % größer als die Datei?

Weil jedes Base64-Zeichen 6 Bit trägt, während jedes Eingabe-Byte 8 Bit trägt. Die kleinste Einheit, die Base64 ohne Rest darstellen kann, sind 3 Bytes (24 Bit = vier 6-Bit-Zeichen), also ist das Ausgabeverhältnis genau 4/3 ≈ 1,33. Es gibt keine Base64-Variante, die das vermeidet, es ist mathematisch in die Kodierung eingebacken.

Funktioniert das kodierte Bild in HTML-E-Mail?

Meistens, aber nicht immer. Apple Mail, das moderne Gmail und die meisten Webmail-Clients stellen data:-Bilder sauber dar. Microsoft Outlook für Desktop hatte in der Vergangenheit uneinheitliche Unterstützung, manche Versionen stellen Data-URIs einwandfrei dar, andere entfernen sie vollständig. Testen Sie in Ihrer Liste der Zielclients, bevor Sie sich in transaktionalen E-Mails auf Base64-Bilder verlassen. Für breite Kompatibilität sind gehostete Bild-URLs immer noch die sicherere Wahl.

Sollte ich stattdessen base64url (mit - und _) verwenden?

Nur, wenn Sie die kodierten Daten in eine URL oder einen Dateinamen einsetzen, wo + und / sonst eine Prozentkodierung benötigen würden. Für HTML-<img src>-Attribute und CSS-background-image-Werte funktioniert das Standardalphabet. RFC 4648 §5 definiert die URL-sichere Variante ausdrücklich für diese URL-/Dateinamen-Fälle und warnt, sie „sollte nicht nur als 'base64' bezeichnet werden“, um Verwechslungen mit dem Standardalphabet zu vermeiden.

Verwandte Tools