Base64 ist eine der am häufigsten verwendeten Kodierungen im Web — und eine der am häufigsten missverstandenen. Es taucht in JWT-Tokens, E-Mail-Anhängen, Data-URLs, API-Payloads, SSH-Schlüsseln und TLS-Zertifikaten auf. Viele Entwickler begegnen Base64 aber erst, wenn etwas bricht: ein JWT, das sich nicht dekodieren lässt, ein in CSS eingebettetes PNG, das als kaputt angezeigt wird, oder eine API, die einen Binär-Upload ablehnt. Dieser Artikel erklärt, was Base64 wirklich ist, warum es erfunden wurde und wann man es verwenden sollte — und wann nicht.

Was Base64 tut

Im Kern nimmt Base64 beliebige Binärdaten und drückt sie mit nur 64 sicheren, druckbaren ASCII-Zeichen aus: A–Z, a–z, 0–9, plus + und /. Drei Eingabe-Bytes (24 Bit) werden zu vier Ausgabezeichen (je 6 Bit). Das Ergebnis ist etwa 33 % größer als die Eingabe, enthält aber nichts, was ein textorientiertes System verwirren würde: keine Zeilenumbrüche, keine Steuerzeichen, keine Nicht-ASCII-Bytes.

Warum es existiert

Frühe E-Mail-Protokolle (SMTP, MIME) wurden um 7-Bit-ASCII herum gebaut. Wer ein PDF oder ein Foto anhängen wollte, dessen rohe Bytes wurden von Zwischen-Mailservern fröhlich verfälscht — mal ein Bit oben abgeschnitten, mal ein Carriage-Return eingefügt. Base64 löste das Problem, indem es Binärdaten wie belanglosen Text aussehen ließ. Dasselbe Problem tauchte für JSON-Payloads, URL-Parameter, HTTP-Header und XML-Bodies wieder auf — überall dort, wo Text vorausgesetzt wird. Base64 ist der Universaladapter.

Heute übliche Einsatzgebiete

Base64 ist keine Verschlüsselung

Dieser Punkt verdient einen eigenen Abschnitt, weil der Fehler häufig ist und teuer werden kann. Base64 hat kein Geheimnis: Jeder mit der kodierten Zeichenkette kann sie in einer Konsolenzeile dekodieren. Verwenden Sie Base64 niemals, um Passwörter, API-Schlüssel oder Nutzerdaten zu schützen. Sehen Sie Zugangsdaten im Quellcode „verschleiert" in Base64, betrachten Sie sie als Klartext. Für echte Geheimhaltung: echte Verschlüsselung (AES, NaCl, libsodium).

Wichtige Varianten

Standard-Base64 verwendet + und /, die in URLs nicht sicher sind. base64url ersetzt sie durch - und _ und lässt das =-Padding weg — das nutzen JWTs und moderne Web-APIs. Es gibt außerdem MIME-Varianten mit fest auf 76 Zeichen umbrochenen Zeilen sowie ältere Fehlimplementierungen, die gelegentlich auftauchen. Wer unsicher ist, prüft, ob der Decoder das exakte Alphabet der Quelle akzeptiert.

Größen-Overhead

Drei Bytes rein, vier Zeichen raus. Der exakte Overhead liegt bei 4⁄3 ≈ 33 % — vor Padding oder Zeilenumbruch. Für kleine Inline-Assets lohnt sich das meistens; ab wenigen Kilobyte ist ein separater HTTP-Request besser.

Wann man es verwendet

Base64 verwenden, wenn Binärdaten durch einen reinen Textkanal müssen und die Größe nicht kritisch ist. Echte Verschlüsselung verwenden, wenn Vertraulichkeit wichtig ist. Und beim Debuggen: zuerst in einen Base64-Decoder einfügen, bevor man den Token selbst beschuldigt — in neun von zehn Fällen ist der Token in Ordnung, und das empfangende System erwartet ein anderes Padding oder Alphabet.