Was ist Base64-Kodierung? Funktionsweise, Bits und Anwendungsfälle
Base64-Kodierung ist ein Verfahren, das beliebige Binärdaten oder Text in eine Zeichenkette aus nur 64 druckbaren ASCII-Zeichen umwandelt, damit die Daten auch Systeme unbeschadet durchlaufen, die eigentlich nur reinen Text sicher verarbeiten können. Das Alphabet besteht aus A-Z, a-z, 0-9, sowie + und /, insgesamt 64 Symbole, ergänzt um = als Füllzeichen am Ende.
Was Base64 tatsächlich tut
Base64 ist keine Verschlüsselung und keine Kompression. Es gibt keinen geheimen Schlüssel, jeder kann eine Base64-Zeichenkette ohne Passwort zurückrechnen, und das Ergebnis ist größer als die Eingabe, nicht kleiner. Genau diese Verwechslung ist der häufigste Fehler im Umgang mit Base64: Jemand “kodiert” ein Passwort oder einen API-Schlüssel in Base64 und hält das für einen Schutz. Ist es nicht. Base64 verändert nur die Darstellung der Daten, nicht ihren Informationsgehalt, jeder mit fünf Minuten Zeit und einem Decoder liest den Klartext wieder heraus.
Der Grund, warum Base64 trotzdem überall auftaucht, ist ein anderer: Manche Übertragungswege, alte Mailserver, bestimmte JSON-Felder, URL-Parameter, sind nicht für beliebige Bytes gebaut. Ein Steuerzeichen oder ein Byte außerhalb des ASCII-Bereichs kann dort Daten beschädigen oder Parser verwirren. Base64 packt jede Art von Daten in ein schmales, garantiert unproblematisches Zeichenset, auf Kosten von etwa 33 Prozent mehr Platz. Je 3 Byte Eingabe werden zu genau 4 Base64-Zeichen.
Wie es funktioniert: “Man” Bit für Bit kodiert
Base64 ist im Kern eine Basisumwandlung, keine Magie. Ein Byte hat 8 Bit, Base64 gruppiert die Daten aber in 6-Bit-Blöcke, weil 2^6 genau 64 ergibt, die Größe des Alphabets. Am Text “Man” lässt sich das komplett nachvollziehen.
Die drei Buchstaben haben die ASCII/Byte-Werte M=77, a=97, n=110, in Binärform:
| Zeichen | Byte-Wert | Binär |
|---|---|---|
| M | 77 | 01001101 |
| a | 97 | 01100001 |
| n | 110 | 01101110 |
Aneinandergereiht ergeben diese drei Bytes 24 Bit: 010011010110000101101110. Diese 24 Bit werden jetzt nicht in 3er-Gruppen zu je 8 Bit gelesen, sondern in 4er-Gruppen zu je 6 Bit:
| 6-Bit-Gruppe | Dezimalwert | Base64-Zeichen |
|---|---|---|
| 010011 | 19 | T |
| 010110 | 22 | W |
| 000101 | 5 | F |
| 101110 | 46 | u |
Jeder Dezimalwert zwischen 0 und 63 zeigt auf genau eine Position im Base64-Alphabet, 19 ist das zwanzigste Zeichen (T), 46 landet bei u. Aus 3 Byte werden so 4 Zeichen, und “Man” wird zu “TWFu”. Nichts davon ist Zufall oder ein Trick, es ist reine Umsortierung von Bits in eine andere Basis.
Padding: warum manche Base64-Strings mit = enden
Das Verfahren oben geht glatt auf, wenn die Eingabe ein Vielfaches von 3 Byte ist. 24 Bit teilen sich sauber in vier 6-Bit-Blöcke. Bei 1 oder 2 Byte Eingabe reicht die Bitmenge nicht für vier volle Blöcke, und genau dafür gibt es das Füllzeichen =.
| Eingabe | Bytes | Base64-Ausgabe | Erklärung |
|---|---|---|---|
| M | 1 | TQ== | 8 Bit reichen für 2 echte Zeichen, der Rest wird mit zwei = aufgefüllt |
| Ma | 2 | TWE= | 16 Bit reichen für 3 echte Zeichen, ein = füllt den letzten Block |
| Man | 3 | TWFu | 24 Bit füllen alle vier Zeichen, kein Padding nötig |
Das = signalisiert dem Decoder also nur, dass am Ende Bits fehlen, die real nicht existierten, es ist reine Buchhaltung, kein Teil der eigentlichen Nutzdaten.
Wo dir Base64 im Alltag begegnet
Ein paar Beispiele, gerechnet mit echten Werten, zeigen den Umfang besser als eine trockene Definition.
“Hello, World!” wird zu SGVsbG8sIFdvcmxkIQ==. Nichts Besonderes, nur Text, der als Bytes durch den gleichen Mechanismus wie oben läuft.
Interessanter ist user:pass1234, das zu dXNlcjpwYXNzMTIzNA== wird. Das ist wörtlich das, was HTTP Basic Authentication im Hintergrund verschickt: Der Header Authorization: Basic <base64(user:pass)> überträgt Benutzername und Passwort, getrennt durch einen Doppelpunkt, base64-kodiert. Wichtig dabei: kodiert, nicht verschlüsselt. Ohne TLS/HTTPS liegt dieses Zugangspaar praktisch im Klartext auf der Leitung.
Auch strukturierte Daten wandern so durch textbasierte Kanäle. {"id":42,"active":true} wird zu eyJpZCI6NDIsImFjdGl2ZSI6dHJ1ZX0=, eine handliche Zeichenkette, die sich ohne Escaping in einen URL-Parameter oder ein anderes JSON-Feld einbetten lässt. Genau dieses Muster steckt auch hinter JSON Web Tokens: Ein JWT besteht aus drei Base64url-Segmenten, getrennt durch Punkte, header.payload.signature. Das mittlere Segment, der Payload, ist eine ganz normale Base64url-kodierte JSON-Struktur und lässt sich mit einem gewöhnlichen Base64/Base64url-Decoder lesen, genau das macht der Decoder weiter unten. Für die Signaturprüfung selbst braucht es allerdings einen spezialisierten JWT-Werkzeugkasten, den dieses Tool nicht ersetzt.
Mehrbyte-Zeichen zeigen eine Eigenheit, die viele überrascht: Base64 arbeitet auf Byte-Ebene, nicht auf Zeichenebene. “café” hat vier sichtbare Zeichen, aber é belegt in UTF-8 zwei Byte, insgesamt also 5 Byte Eingabe. Das Ergebnis ist Y2Fmw6k=, 8 Base64-Zeichen statt der 6, die man bei naiver Zeichenzählung erwarten würde. Noch deutlicher wird es bei einem Emoji: 🚀 ist ein einzelnes sichtbares Zeichen, aber 4 Byte in UTF-8, kodiert zu 8J+agA==. Der Rechner zählt Bytes, nicht Buchstaben.
Weitere gängige Fundorte: Anhänge in E-Mails werden per MIME base64-kodiert, damit binäre Dateien einen textbasierten E-Mail-Transport überstehen, und data:-URLs in CSS oder HTML betten kleine Bilder direkt im Base64-Format ein, ohne eine zusätzliche HTTP-Anfrage auszulösen.
Eigenen Text kodieren oder dekodieren
Tippe einen Text ein und sieh dir die Base64-Ausgabe live an, oder füge eine Base64-Zeichenkette ein, um sie zurück in Klartext zu verwandeln.
Häufige Fehler und Sonderfälle
Base64 mit Sicherheit verwechseln. Das ist der Klassiker: Ein Passwort, ein Token oder eine Kreditkartennummer wird base64-kodiert und dann so behandelt, als wäre sie geschützt. Das ist ein handfestes Sicherheitsproblem, kein Randfall. Base64 verbirgt Daten vor dem flüchtigen Blick, aber jeder Decoder macht die Kodierung in Millisekunden rückgängig. Für echten Schutz braucht es Verschlüsselung mit einem Schlüssel, den ein Angreifer nicht hat.
Standard-Base64 für URLs verwenden. Die Zeichen + und / sind in URLs, Query-Strings und Dateinamen problematisch, ein + wird dort manchmal als Leerzeichen interpretiert, ein / kann als Pfadtrenner missverstanden werden. Deshalb gibt es die Variante Base64URL, die - statt + und _ statt / verwendet, oft auch ganz ohne Padding-Zeichen. Wenn eine Base64-ähnliche Zeichenkette in einer URL kein + oder / enthält und kein = am Ende hat, ist das meist Base64URL, keine defekte Base64-Ausgabe.
Leerzeichen, Zeilenumbrüche oder fehlendes Padding. Manche Systeme brechen lange Base64-Ausgaben in mehrere Zeilen um (das ist bei MIME-Anhängen sogar üblich), aber ein strikter Decoder verweigert dann oft die Arbeit, wenn diese Umbrüche mitkopiert werden. Genauso führt ein fehlendes = am Ende häufig zu einem Fehler statt zu einem stillen Rateversuch.
Mehrbyte-Text falsch einschätzen. Wie oben bei café und 🚀 gezeigt, entspricht die Zeichenanzahl eines Strings nicht der Byteanzahl, sobald Akzente, kyrillische oder asiatische Schriftzeichen oder Emojis im Spiel sind. Wer die Base64-Ausgabelänge überschlägt, sollte immer von Byte-Anzahl ausgehen, nicht von sichtbaren Zeichen.
Versehentliches doppeltes Kodieren. Wird eine bereits base64-kodierte Zeichenkette ein zweites Mal kodiert, entsteht eine gültige, aber komplett andere Base64-Ausgabe. Beim einmaligen Dekodieren kommt dann wirres Kauderwelsch heraus, nicht der ursprüngliche Text, weil ja erst die zweite Kodierschicht entfernt wurde. Bei unerwarteten Zeichenfolgen im Ergebnis lohnt sich die Kontrolle, ob die Eingabe schon vorher kodiert war.
Häufig gestellte Fragen
Ist Base64 dasselbe wie Verschlüsselung? Nein. Base64 ist eine reversible Kodierung ohne geheimen Schlüssel, jeder kann sie mit einem Standard-Decoder rückgängig machen. Verschlüsselung braucht einen Schlüssel und macht Daten ohne diesen Schlüssel unlesbar, das leistet Base64 nicht.
Warum wird die Base64-Ausgabe größer als die Eingabe? Weil jedes Byte (8 Bit) in kleinere 6-Bit-Blöcke zerlegt und jeder Block als ein eigenes Zeichen dargestellt wird. Aus 3 Byte Eingabe werden 4 Zeichen Ausgabe, ein Zuwachs von etwa 33 Prozent, unabhängig vom Inhalt der Daten.
Wofür stehen die = Zeichen am Ende einer Base64-Zeichenkette? Sie sind reines Padding. Sie erscheinen, wenn die Eingabelänge kein Vielfaches von 3 Byte ist, und zeigen dem Decoder an, wie viele der letzten Bits nur Füllung ohne echten Dateninhalt sind. Ein oder zwei =-Zeichen sind normal und kein Fehler.
Was ist der Unterschied zwischen Base64 und Base64URL? Base64URL ersetzt die beiden in URLs problematischen Zeichen + und / durch - und _, und lässt Padding häufig ganz weg. Damit kann eine Base64URL-Zeichenkette direkt in einer URL, einem Dateinamen oder einem JWT stehen, ohne dass Sonderzeichen escaped werden müssen.
Kodiert dieses Tool auch JWT-Tokens? Der Decoder kann das mittlere Payload-Segment eines JWT lesen, weil es einfach Base64url-kodiertes JSON ist, du fügst das Segment zwischen den beiden Punkten ein und liest die Claims direkt heraus. Für die Signaturprüfung selbst ist ein dediziertes JWT-Werkzeug nötig, das ist nicht Aufgabe eines allgemeinen Base64-Decoders.