Was ist Base64-Kodierung und wann setzt man sie ein

Wenn Sie mit APIs, E-Mail-Systemen oder Webentwicklung arbeiten, sind Sie Base64 begegnet, auch wenn Sie es nicht erkannt haben. Diese langen Zeichenketten aus Buchstaben und Ziffern, die am Anfang eines E-Mail-Anhangs, in einer data:-URL in CSS oder im mittleren Segment eines JWT-Tokens wie Kauderwelsch aussehen? Das ist Base64. Es ist eines der ältesten und still tragenden Stücke der Internet-Klempnerei, und fast jede Software, die Sie nutzen, lehnt sich irgendwo darauf.

Eine kurze Geschichte von Base64

Base64 gehört zu einer Familie, die «radix-64» oder «druckbare Kodierungen» heißt, deren Aufgabe es ist, beliebige Bytes mit dem kleinen Alphabet von Zeichen darzustellen, das ein textbasiertes System garantiert unverändert durchlässt. Das früheste weit verbreitete Mitglied ist uuencode, von Mary Ann Horton an der UC Berkeley um 1980 geschrieben, um binäre Dateien über Usenet und E-Mail zu verschicken, als diese Systeme alles über 7-Bit-ASCII verstümmelten.

Das Base64-Alphabet selbst wurde erstmals in RFC 989 (1987) für Privacy-Enhanced Mail (PEM) standardisiert, einen frühen Versuch signierter und verschlüsselter E-Mail. PEM ist gestorben, aber sein Kodierungsschema überlebte und wurde in RFC 1421 (1993) und dann in der MIME-Spezifikation (RFC 1521 und 1522 in 1993, überarbeitet zu RFCs 2045-2049 in 1996) kanonisiert. MIME machte Base64 zur Standardweise, binäre Dateien an E-Mails anzuhängen, und von dort breitete sich die Kodierung auf nahezu jeden reinen Texttransport im Internet aus.

2006 konsolidierte die IETF die verstreuten Base64-Definitionen in RFC 4648, die Base64, Base32 und Base16 in einem einzigen Dokument definiert. RFC 4648 definierte in Abschnitt 5 auch die URL-sichere Variante, die die beiden nicht-URL-freundlichen Zeichen (+ und /) gegen - und _ tauschte. JSON Web Tokens (RFC 7519, 2015) standardisierten auf URL-sicheres Base64 mit entferntem Padding. Heute hängen jeder E-Mail-Anhang, jedes PEM-kodierte Zertifikat, jede data:-URL, jedes JWT und jede multipart-Upload-Grenze von Base64 ab.

Wie Base64 funktioniert: die Mathematik

Base64 nimmt drei Eingabe-Bytes (24 Bit) und schreibt sie als vier Ausgabezeichen (je 6 Bit) um, mit einem 64-Symbol-Alphabet. Die Zuordnung ist fest:

So wird aus Hello:

• ASCII-Bytes: 0x48 0x65 0x6C 0x6C 0x6F (5 Bytes)
• Binär: 01001000 01100101 01101100 01101100 01101111
• In 6-Bit-Blöcke umgruppiert: 010010 000110 010101 101100 011011 000110 1111
• Letzter Block zu kurz, mit Null-Bits aufgefüllt: 010010 000110 010101 101100 011011 000110 111100
• Nachschlagen: S G V s b G 8 (nur 7 Zeichen aus 6 Gruppen à 6 Bit = 36 Bit, Padding für die fehlenden 4)
• Padding: = anhängen, um auf ein Vielfaches von 4 Ausgabezeichen zu kommen: SGVsbG8=

Die Ausgabe ist immer ein Vielfaches von 4 Zeichen. Wenn die Eingabelänge modulo 3 gleich 1 ist, bekommen Sie zwei = Padding-Zeichen; ist sie 2, eines; ist sie 0, keines. Padding wird manchmal entfernt (besonders in JWT und in URL-Fragmenten), und Dekoder müssen das tolerieren.

Der 33-%-Overhead kommt aus dieser 3-zu-4-Expansion: jedes 3 Bytes der Eingabe werden 4 Zeichen der Ausgabe, ein Drittel mehr. Es gibt keinen Weg, das zu reduzieren, ohne das Alphabet zu ändern (Base85 / Ascii85 expandiert nur um 25 % mit 85 druckbaren Zeichen, zum Preis eines komplexeren Encoders).

Gängige Anwendungsfälle

E-Mail-Anhänge. SMTP, das Protokoll, das 95 % der E-Mails zwischen Servern transportiert, wurde 1982 (RFC 821) für 7-Bit-ASCII entworfen. Jeder binäre Anhang, den Sie senden (ein Bild, ein PDF, ein ZIP), wird vor der Übertragung von Ihrem Mailclient in Base64 kodiert und vom Empfänger-Client dekodiert. Die MIME-Header in der E-Mail sagen dem Empfänger, welche Teile Base64 und welche reiner Text sind.

Data-URLs in HTML und CSS. Eine URL data:image/png;base64,iVBORw0KGgo... bettet eine binäre Datei direkt ins Dokument ein. Nützlich für kleine Icons unter 1-2 KB, wo die eingesparte HTTP-Anfrage den 33-%-Overhead und den Verlust des Cachings überwiegt.

API-Nutzlasten. Wenn eine JSON- oder XML-API einen binären Wert annehmen muss (eine hochgeladene Datei, eine Unterschrift, ein Profilbild), ist das Standardmuster, die Bytes in Base64 zu kodieren und als String-Feld zu schicken. Der Empfänger dekodiert sie serverseitig. So funktioniert die Bildeingabe von OpenAI, so empfängt Stripe Datei-Uploads, und so akzeptieren die meisten Cloud-Funktionen Binäreingaben.

HTTP-Basic-Authentifizierung. Der Header Authorization: Basic <token> trägt ein Base64-kodiertes username:password-Paar (RFC 7617). Das ist Kodierung, keine Verschlüsselung: wer den Header sieht, sieht das Passwort. Basic Auth verlangt aus diesem Grund HTTPS.

Zertifikate und Schlüssel. PEM-Dateien (-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----) umhüllen einen Base64-kodierten Blob DER-kodierter ASN.1-Bytes. Jedes TLS-Zertifikat, jede SSH-Schlüsseldatei, jedes Code-Signing-Zertifikat ist Base64 in einem PEM-Umschlag.

JWT-Tokens. Ein JWT sind drei URL-sichere Base64-Segmente, durch Punkte getrennt: <header>.<payload>.<signature>. Die Base64-Kodierung erlaubt einem JWT, sicher in Headern, URLs und Cookies zu reisen.

Wie kodieren und dekodieren

1. Kodieren oder dekodieren wählen: die Konvertierungsrichtung auswählen.
2. Text einfügen oder Datei hochladen: Text direkt eingeben oder eine Datei per Drag-and-drop (bis 5 MB für browserseitige Kodierung).
3. Variante wählen: Standard-Base64 für E-Mail und Zertifikate, URL-sicher für JWT und URL-Fragmente. Das Werkzeug nutzt Standard als Voreinstellung.
4. Ergebnis kopieren: die Ausgabe aktualisiert sich sofort. In die Zwischenablage kopieren oder den Download-Button für lange Ausgaben nutzen.

Varianten von Base64

Mehrere Base64-ähnliche Kodierungen existieren für spezifische Situationen:

Meist wollen Sie entweder Standard- oder URL-sicheres Base64. Die anderen tauchen in spezifischen Protokollen auf.

Wann Base64 verwenden

Verwenden Sie es, wenn:

• Sie ein kleines Bild (unter 5 KB) direkt in HTML oder CSS einbetten müssen und damit eine HTTP-Anfrage sparen.
• Eine API binäre Daten als Textstring in einer JSON- oder XML-Nutzlast verlangt.
• Sie binäre Daten durch ein System schicken, das nur Text unterstützt (E-Mail, Log-Einträge, Query-Parameter).
• Sie ein JWT, Zertifikat, Schlüssel oder irgendeinen strukturierten Binärblob kodieren.
• Sie eine deterministische, in sich geschlossene String-Repräsentation brauchen, die jede Sprache dekodieren kann.

Verwenden Sie es nicht, wenn:

• Die Datei groß ist. Base64 fügt 33 % Overhead hinzu, verhindert das Browser-Caching des Binärs als separate Ressource und zwingt den ganzen Blob durch den Seiten-Parser.
• Sie Sicherheit brauchen. Base64 ist keine Verschlüsselung; es ist trivial umkehrbar.
• Sie die Datei normal ausliefern können. Ein einfaches <img src="photo.jpg"> ist effizienter als eine Base64-Data-URL für alles oberhalb weniger KB.
• Sie eine kompakte Repräsentation brauchen. Hex ist einfacher, wenn Größe egal ist; Base85 ist dichter, wenn sie zählt.

Häufige Fallen

• Kodierung mit Verschlüsselung verwechseln. Base64 ist von jedem in Millisekunden umkehrbar. Ein «Geheimnis» durch Base64 zu jagen schützt es vor nichts außer einem Blick über die Schulter.
• Die 33-%-Größenstrafe. Ein 1-MB-Bild wird ein 1,33-MB-String, und inline Data-URLs werden mit dem Eltern-HTML bei jedem Besuch heruntergeladen, ohne separaten Cache.
• Zeilenumbrüche in MIME-Base64. Die MIME-Variante fügt alle 76 Zeichen \r\n ein. Wenn Sie MIME-Base64 in einen JSON-Wert oder eine URL einfügen, schlägt es fehl; entfernen Sie vorher die Zeilenumbrüche.
• Padding-Entfernung bei JWT. JWT nutzt URL-sicheres Base64 mit entferntem = Padding. Eine Bibliothek, die Padding strikt verlangt, weist gültige JWTs zurück; eine, die keines erzeugt, baut Tokens, die andere Bibliotheken zurückweisen. RFC 7515 schreibt «kein Padding» für den JWS-Standard vor.
• URL-sicher vs. Standard durcheinander. Eine URL-sichere Zeichenkette mit einem Standard-Dekoder zu dekodieren schlägt an den - und _-Zeichen fehl; eine Standard-Zeichenkette mit einem URL-sicheren Dekoder schlägt an + und / fehl.
• Unicode-Eingabehandling. Base64 operiert auf Bytes, nicht auf Zeichen. Wenn Sie eine UTF-8-Emoji-Zeichenkette in Base64 kodieren, müssen Sie sich zuerst auf eine Byte-Kodierung festlegen (fast immer UTF-8). Verschiedene Runtimes haben verschiedene Standardwerte; spezifizieren Sie es explizit.
• Streaming-Teil-Dekoder. Ein korrekt implementierter Base64-Stream-Dekoder wartet auf Gruppen von 4 Eingabezeichen, bevor er 3 Ausgabe-Bytes ausgibt. Naive Implementierungen, die Zeichen für Zeichen dekodieren, erzeugen Müll.
• Abschließende Leerzeichen und BOM. Manche Editoren hängen beim Speichern einen Zeilenumbruch oder ein UTF-8-Byte-Order-Mark an. Dieses Extrabyte ändert die Base64-Ausgabe. Diff'en Sie Ihr kodiertes Ergebnis gegen eine Upstream-Quelle, wenn Sie unerwartete Abweichungen sehen.
• + als Leerzeichen in URLs interpretiert. Standard-Base64s + wird ` ` (Leerzeichen), wenn ein URL-Parser percent-decodiert. Genau deshalb existiert URL-sicheres Base64.

Alternativen und benachbarte Kodierungen

Base64 ist der Standard, nicht die einzige Option. Die richtige Wahl hängt vom Kanal und vom Größenbudget ab.

Für den Großteil der täglichen Arbeit ist die Antwort Base64 (Standard oder URL-sicher). Für binäre Datei-Uploads über HTTP ist die richtige Antwort meist multipart/form-data, das gar nicht kodiert.

Datenschutz und der Encoder

Der Base64-Encoder und -Decoder läuft vollständig in Ihrem Browser. Der eingegebene Text oder die Datei wird von JavaScript auf Ihrem Gerät verarbeitet, das Ergebnis auf der Seite gerendert, und nichts wird an einen Server geschickt. Nichts wird protokolliert, nichts bleibt nach dem Verlassen der Seite gespeichert, und kein Analytics-Tag sieht den Inhalt. Für Dinge, die Sie in Base64 kodieren könnten (PEM-Zertifikate, private Schlüssel, JWT-Nutzlasten aus Produktionssystemen, Entwürfe von API-Anfragen mit echten Kundendaten), ist dieser strikt lokale Ablauf die richtige Voreinstellung. Das gesamte Werkzeug läuft offline, sobald die Seite geladen ist, was Sie überprüfen können, indem Sie das Netzwerk abschalten und dieselbe Eingabe erneut kodieren.