Base64-Kodierung wandelt Binärdaten in ein 64-Zeichen-Textalphabet (A-Z, a-z, 0-9, plus zwei Symbole) um, damit sie sicher durch textbasierte Systeme wie URLs, JSON, E-Mail und CSS übertragen werden können. Zum Dekodieren kehren Sie den Prozess um und erhalten die ursprünglichen Bytes zurück. Es handelt sich um eine Kodierung, nicht um eine Verschlüsselung: Jeder kann sie dekodieren, daher bietet sie keinerlei Sicherheit.
Der Grund für die Existenz von Base64 ist einfach. Viele Kanäle wurden für Text ausgelegt und haben Probleme mit rohen Binärdaten. Ein JSON-String kann keine beliebigen Bytes enthalten, ein E-Mail-Textkörper musste historisch 7-Bit-ASCII sein, und eine URL enthält reservierte Zeichen mit besonderer Bedeutung. Base64 formt jedes binäre Datenpaket in sichere, druckbare Zeichen um, auf Kosten einer etwa 33% größeren Datenmenge, da es 3 Bytes in 4 Zeichen packt.
Wie Base64-Kodierung funktioniert#
Der Mechanismus ist einmal verstanden. Base64 nimmt Ihre Bytes in Dreiergruppen. Drei Bytes sind 24 Bits, die sich gleichmäßig in vier 6-Bit-Gruppen aufteilen. Jede 6-Bit-Gruppe (ein Wert von 0 bis 63) wird einem Zeichen im Base64-Alphabet zugeordnet. So werden alle 3 Eingabebytes zu genau 4 Ausgabezeichen.
Wenn die Eingabe kein glattes Vielfaches von 3 Bytes ist, füllt der Encoder das Ende auf. Ein übrig gebliebenes Byte erzeugt zwei Zeichen plus ==; zwei übrig gebliebene Bytes erzeugen drei Zeichen plus =. Dieses nachgestellte = ist Auffüllung, keine Daten, und deshalb enden Base64-Strings so oft mit einem oder zwei Gleichheitszeichen.
Eingabebytes: M a n
ASCII: 77 97 110
Binär: 01001101 01100001 01101110
6-Bit-Gruppen: 010011 010110 000101 101110
Base64: T W F u
So kodiert Man zu TWFu. Dekodieren Sie TWFu und Sie erhalten Man zurück, Byte für Byte. Es geht nichts verloren, da Base64 vollständig umkehrbar ist.
Die drei Varianten, die oft für Verwirrung sorgen#
Hier ist die Lücke, die die meisten Erklärungen offen lassen: „Base64“ ist nicht ein festes Format. Es gibt drei gängige Varianten, und die falsche zu verwenden, ist eine häufige Ursache für „es dekodiert zu Müll“-Fehler.
| Variante | Zeichen 62 & 63 | Padding | Verwendung |
|---|---|---|---|
| Standard (RFC 4648) | + und / | =-Padding | JSON, allgemeine Daten, die meisten APIs |
| URL-sicher (RFC 4648 §5) | - und _ | oft kein Padding | URLs, Dateinamen, JWT-Segmente |
| MIME (RFC 2045) | + und / | =-Padding | E-Mail; Zeilenumbruch alle 76 Zeichen |
Die Unterschiede sind in der Praxis relevant:
- Standard ist die Voreinstellung. Sie verwendet
+und/, was in JSON und den meisten Anfragekörpern in Ordnung ist. - URL-sicher ersetzt
+durch-und/durch_, da+und/reservierte Bedeutungen in einer URL haben (ein+kann zu einem Leerzeichen werden, ein/ist ein Pfadtrenner). Diese Variante wird von JWTs für ihre Header- und Payload-Segmente verwendet. Padding wird oft weggelassen. - MIME ist Standard-Base64, fügt aber alle 76 Zeichen einen Zeilenumbruch ein, damit alte E-Mail-Systeme nicht an langen Zeilen ersticken. Wenn man diese eingebetteten Zeilenumbrüche einem strengen Decoder zuführt, der sie nicht erwartet, kann dies fehlschlagen.
Tipp: Wenn eine Base64-Zeichenfolge zu Unsinn dekodiert wird, überprüfen Sie zuerst das Alphabet. Ein
-oder_in den Daten bedeutet, dass es URL-sicher ist und Sie es als Standard dekodieren, oder umgekehrt. Nicht übereinstimmende Varianten sind der häufigste Base64-Fehler.
Inlining von Bildern als Data-URLs#
Die praktischste Anwendung von Base64 im Web ist die Data-URL: Einbetten einer kleinen Datei direkt in HTML oder CSS, anstatt darauf zu verlinken. Eine Data-URL hat eine feste Form:
data:[<MIME-Typ>][;base64],<codierte-Daten>
Für ein winziges PNG-Symbol wird das codierte Bild zu einem String, den Sie direkt in ein CSS background-image einfügen können:
.icon {
background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...");
width: 16px;
height: 16px;
}
Der Browser decodiert das Base64, rekonstruiert das PNG und rendert es ohne separate Netzwerkanfrage. Das Gleiche funktioniert inline in HTML:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." alt="Symbol" />
Wann Inlining hilft und wann es schadet#
Dies ist die Abwägungsfrage, die Erklärungen oft auslassen. Inlining ist nicht kostenlos, da Base64 die Datei um etwa 33% aufbläht und die eingebetteten Bytes nicht separat von der Seite oder dem Stylesheet gecacht werden können.
Betten Sie eine Data-URL ein, wenn:
- Das Asset winzig ist (ein kleines Symbol, ein 1x1-Abstandshalter, ein SVG unter einigen Kilobyte).
- Sie eine zusätzliche HTTP-Anfrage für ein kritisches Above-the-Fold-Bild vermeiden möchten.
- Das Asset nur einmal verwendet wird und sich selten ändert.
Verlinken Sie stattdessen auf eine normale Datei, wenn:
- Das Bild groß ist. Base64-Aufblähung plus fehlendes separates Caching machen die Seite schwerer und langsamer.
- Das Asset auf vielen Seiten wiederverwendet wird, wo eine gecachte externe Datei klar überlegen ist.
- Das Bild sich häufig ändert, da eine eingebettete Kopie bei jeder Änderung den gesamten Seiten- oder Stylesheet-Cache ungültig macht.
Die Faustregel: Betten Sie kleine, einmalige, kritische Assets ein; verlinken Sie alles andere.
Base64 ist keine Verschlüsselung#
Dieser Punkt verwirrt Anfänger ständig, daher lohnt es sich, ihn klar zu sagen. Base64 ist für jeden ohne Schlüssel und ohne Geheimnis umkehrbar. Es verschleiert nichts. Wenn Sie ein Passwort oder einen API-Schlüssel mit Base64 kodieren, haben Sie ihn nicht geschützt; Sie haben ihn nur für einen Menschen, der den Text überfliegt, etwas weniger offensichtlich gemacht. Ein JWT-Payload ist base64url-kodiert, genau deshalb kann jeder ihn dekodieren und seine Behauptungen ohne das Signaturgeheimnis lesen.
Wenn Sie tatsächlich Vertraulichkeit benötigen, verwenden Sie echte Verschlüsselung. Base64 dient dem sicheren Transport von Bytes durch Textkanäle, nicht dem Verstecken. Für den speziellen JWT-Aspekt erklärt unser Leitfaden zum sicheren Dekodieren versus Verifizieren eines JWT, warum das Lesen eines Tokens trivial ist, während das Vertrauen darauf eine Signaturprüfung erfordert.
Sicher codieren und decodieren in Ihrem Browser#
Wie bei SQL und JWTs sind die Daten, die Sie base64-codieren, oft sensibel: eine Konfigurationsdatei, ein privater Schlüssel, ein internes Bild. Wenn Sie diese in ein serverseitiges Tool einfügen, werden diese Bytes von Ihrem Rechner übertragen. Ein Codec, der vollständig im Browser läuft, hält alles lokal.
Schritt 1: Text oder Datei codieren#
Öffnen Sie den kostenlosen base64-Encoder und Decoder, fügen Sie Text ein oder legen Sie eine Datei ab, und wählen Sie Ihre Variante (Standard oder URL-sicher). Bei einem Bild liest das Tool die Datei, codiert die Bytes und erstellt eine fertig einfügbare data:-URL mit dem korrekten MIME-Typ, alles auf der Seite, sodass die Datei nie hochgeladen wird.
Schritt 2: Decodieren und Vorschau anzeigen#
Fügen Sie einen base64-String ein, um ihn zu decodieren. Handelt es sich um Text, erhalten Sie den Text zurück. Bei einem codierten Bild zeigt der Codec das decodierte Bild direkt als Vorschau an, sodass Sie die Gültigkeit prüfen können, statt auf einen Binärblock zu starren. Wenn die Eingabe kein druckbarer Text ist, wird auf eine Hex-Darstellung zurückgegriffen, damit Sie die Rohbytes inspizieren können.
Schritt 3: Die Data-URL in Ihr CSS oder HTML kopieren#
Nehmen Sie die generierte data:image/...;base64,...-Zeichenkette und setzen Sie sie in ein background-image oder ein <img src> ein. Verwenden Sie dies nur für kleine, kritische Assets gemäß den obigen Inline-Regeln und verlinken Sie größere oder wiederverwendete Bilder normal.
Kurzreferenz#
- Base64 bildet alle 3 Bytes auf 4 Textzeichen ab, wodurch die Daten um etwa 33% wachsen.
- Nachgestelltes
=ist Padding, keine Daten. - Standard verwendet
+und/; URL-sicher verwendet-und_; MIME bricht Zeilen bei 76 Zeichen um. - Eine Data-URL ist
data:<mime>;base64,<data>und bindet ein Asset ohne zusätzliche Anfrage ein. - Kleine, einmalige Assets inline einbinden; große oder wiederverwendete verlinken.
- Base64 ist Kodierung, keine Verschlüsselung; es bietet keine Sicherheit.
Für Bilder speziell erstellt der dedizierte Bild-zu-Base64-Konverter die Data-URL mit einer Live-Vorschau, und der Molixa Base64-Codec verarbeitet Text, Dateien und den Hex-Dump-Fallback für nicht-textuelle Eingaben, vollständig clientseitig.
Häufig gestellte Fragen#
Wofür wird Base64-Kodierung verwendet? Base64 wandelt Binärdaten in Klartext um, damit sie über textbasierte Kanäle wie URLs, JSON-Payloads, E-Mail-Inhalte und CSS-Daten-URLs übertragen werden können. So können Sie ein Bild direkt in ein Stylesheet einbetten, eine Datei in einem JSON-Feld transportieren oder Binärdaten in einem URL-Parameter übergeben, ohne dass diese durch reservierte Zeichen beschädigt werden.
Ist Base64-Kodierung sicher oder verschlüsselt? Weder noch. Base64 ist von jedem vollständig umkehrbar, ohne Schlüssel oder Geheimnis, und bietet daher keinerlei Sicherheit. Es formt Bytes lediglich in sichere druckbare Zeichen für den Transport um. Die Kodierung eines Passworts oder API-Schlüssels in Base64 schützt diese nicht. Wenn Sie echte Vertraulichkeit benötigen, verwenden Sie echte Verschlüsselung, nicht Base64.
Wie konvertiere ich ein Bild in eine Base64-Daten-URL?
Kodieren Sie die Bildbytes in Base64 und umschließen Sie sie als data:image/png;base64,<kodierte-daten> (passen Sie den MIME-Typ an die Datei an). Fügen Sie diese Zeichenfolge in ein CSS background-image oder ein HTML <img src> ein, und der Browser dekodiert und rendert sie ohne zusätzliche Anfrage. Ein clientseitiger Codec erstellt die vollständige Daten-URL für Sie und zeigt eine Vorschau des Ergebnisses an.
Was ist der Unterschied zwischen Standard- und URL-sicherer Base64-Kodierung?
Standard-Base64 verwendet + und / für die letzten beiden Zeichen, was in JSON und den meisten APIs in Ordnung ist. URL-sichere Base64 ersetzt diese durch - und _, da + und / in URLs reserviert sind, und entfernt oft die =-Auffüllung. JWT-Header- und Payload-Segmente verwenden die URL-sichere Variante. Die Dekodierung mit dem falschen Alphabet führt zu Müll.
Warum hat meine Base64-Zeichenfolge Gleichheitszeichen am Ende?
Dabei handelt es sich um Auffüllung. Base64 arbeitet in Gruppen von 3 Eingabebytes, die 4 Zeichen erzeugen. Wenn die Eingabelänge kein Vielfaches von 3 ist, fügt der Kodierer ein oder zwei =-Zeichen an, um die letzte Gruppe aufzufüllen. Ein einzelnes nachfolgendes Byte ergibt ==, zwei nachfolgende Bytes ergeben =. Die Auffüllung enthält keine Daten, und einige URL-sichere Kodierer lassen sie weg.
Sollte ich Bilder als Base64 einbetten oder auf Dateien verlinken? Betten Sie nur kleine, einmalige, kritische Assets wie ein winziges Symbol oder ein Bild oberhalb der Falz ein, bei dem das Einsparen einer HTTP-Anfrage wichtig ist. Base64 bläht die Größe um etwa 33% auf, und eingebettete Daten können nicht separat von der Seite zwischengespeichert werden. Daher ist für große oder häufig wiederverwendete Bilder eine normale verlinkte Datei, die der Browser zwischenspeichert, schneller.
