Was ist Base64 und wozu braucht man es?
Base64 ist ein Kodierungsverfahren, das beliebige Binärdaten in druckbare ASCII-Zeichen umwandelt. Der Name verrät es bereits: Es verwendet ein Alphabet aus 64 Zeichen (A–Z, a–z, 0–9, + und /), plus das Gleichheitszeichen = als Padding. Das Verfahren ist in RFC 4648 standardisiert.
Der häufigste Grund für Base64: Transportprotokolle, die nur Text verarbeiten können. SMTP (E-Mail) wurde in den 1980ern für 7-Bit-ASCII entworfen. Wenn du ein Bild an eine E-Mail anhängst, wird es Base64-kodiert, damit es durch Server laufen kann, die Binärdaten nicht verstehen.
Wichtig: Base64 ist keine Verschlüsselung und kein Sicherheitsmechanismus. Es bietet null Schutz — jeder kann Base64 dekodieren. Wenn du Daten schützen willst, verwende echte Verschlüsselung (AES, ChaCha20) und signiere mit HMAC oder digitalen Signaturen.
Die Kodierung erhöht die Datenmenge um ungefähr 33 %. Aus 3 Bytes Input werden 4 Zeichen Output. Das ist der Preis für Textkompatibilität — ein wichtiger Faktor, wenn du überlegst, ob Base64 für deinen Anwendungsfall sinnvoll ist.
Wie der Base64-Algorithmus funktioniert
Der Algorithmus arbeitet in drei Schritten: Zuerst wird der Input-Bytestream in Gruppen von je 3 Bytes (24 Bits) aufgeteilt. Dann wird jede 24-Bit-Gruppe in vier 6-Bit-Blöcke zerlegt. Schließlich wird jeder 6-Bit-Block (Wert 0–63) über eine Lookup-Tabelle in ein druckbares Zeichen umgewandelt.
Wenn die Eingabe nicht durch 3 teilbar ist, kommt Padding ins Spiel. Bei einem übrigen Byte werden zwei Zeichen plus == ausgegeben. Bei zwei übrigen Bytes sind es drei Zeichen plus ein einzelnes =. Manche Implementierungen lassen das Padding weg — das funktioniert beim Dekodieren trotzdem, ist aber nicht standardkonform.
Ein konkretes Beispiel: Der String "Hi" besteht aus den Bytes 0x48 (H) und 0x69 (i). In Binär: 01001000 01101001. Aufgeteilt in 6-Bit-Blöcke: 010010 000110 1001xx. Die fehlenden Bits werden mit Nullen aufgefüllt: 010010 000110 100100. Das ergibt die Indizes 18, 6, 36 → Zeichen S, G, k, plus ein = als Padding. Ergebnis: "SGk=".
Die URL-sichere Variante (Base64url) ersetzt + durch - und / durch _, damit die kodierten Daten direkt in URLs verwendet werden können ohne zusätzliches Escaping. JWT-Tokens verwenden zum Beispiel ausschließlich Base64url.
// Base64-Kodierung in JavaScript (Browser & Node.js)
const text = 'Hallo Welt';
// Kodieren
const encoded = btoa(text); // "SGFsbG8gV2VsdA=="
// Dekodieren
const decoded = atob(encoded); // "Hallo Welt"
// Für Unicode-Strings (Umlaute etc.)
const unicodeText = 'Ärger mit Ümlauten';
const safeEncoded = btoa(unescape(encodeURIComponent(unicodeText)));
const safeDecoded = decodeURIComponent(escape(atob(safeEncoded)));
// Node.js Buffer API
const buf = Buffer.from(text, 'utf-8');
const b64 = buf.toString('base64'); // "SGFsbG8gV2VsdA=="Häufige Anwendungsfälle in der Praxis
Data-URIs: Du kannst kleine Bilder direkt ins HTML oder CSS einbetten mit data:image/png;base64,.... Das spart einen HTTP-Request, lohnt sich aber nur für Dateien unter 2–3 KB. Größere Bilder blähen das HTML auf und können nicht separat gecacht werden.
API-Authentifizierung: HTTP Basic Auth kodiert Benutzername:Passwort als Base64 im Authorization-Header. Das ist bewusst kein Sicherheitsmechanismus — der Header wird nur kodiert, damit Sonderzeichen den HTTP-Parser nicht stören. Ohne HTTPS ist das Passwort im Klartext lesbar.
JWT-Tokens: JSON Web Tokens bestehen aus drei Base64url-kodierten Teilen (Header, Payload, Signatur), getrennt durch Punkte. Die Payload ist nicht verschlüsselt — jeder kann sie dekodieren. Die Sicherheit liegt in der Signatur, nicht in der Kodierung.
E-Mail-Anhänge: MIME verwendet Base64 als Content-Transfer-Encoding für Binäranhänge. Auch S/MIME-Zertifikate und PEM-Dateien (-----BEGIN CERTIFICATE-----) sind Base64-kodiert. Das PEM-Format ist im Grunde DER-Binärdaten plus Base64 plus Header/Footer-Zeilen.
Base64 und Unicode: Die häufigste Falle
Die Browser-Funktion btoa() akzeptiert nur Zeichen im Bereich 0x00–0xFF (Latin-1). Sobald ein String Zeichen außerhalb dieses Bereichs enthält — Umlaute in bestimmten Kontexten, Emojis, CJK-Zeichen — wirft btoa() einen InvalidCharacterError.
Die Lösung: Zuerst den String in UTF-8-Bytes umwandeln, dann diese Bytes Base64-kodieren. In modernem JavaScript geht das elegant mit TextEncoder: new TextEncoder().encode(text) liefert ein Uint8Array, das du dann kodieren kannst.
In Node.js ist das kein Problem: Buffer.from(text, "utf-8").toString("base64") funktioniert mit jedem Unicode-String. Der Buffer übernimmt die UTF-8-Konvertierung automatisch.
Beim Dekodieren musst du den umgekehrten Weg gehen: Base64 dekodieren → Bytes erhalten → UTF-8 dekodieren. Wenn du diesen Schritt vergisst, bekommst du verstümmelte Umlaute oder Mojibake. Das ist der häufigste Grund für kaputte Sonderzeichen in Webanwendungen.
// Moderner Ansatz mit TextEncoder/TextDecoder
function toBase64(str) {
const bytes = new TextEncoder().encode(str);
const binary = Array.from(bytes, b => String.fromCodePoint(b)).join('');
return btoa(binary);
}
function fromBase64(b64) {
const binary = atob(b64);
const bytes = Uint8Array.from(binary, c => c.codePointAt(0));
return new TextDecoder().decode(bytes);
}
// Funktioniert mit allen Unicode-Zeichen
toBase64('Ärger 🚀'); // "w4RyZ2VyIPCfmoA="
fromBase64('w4RyZ2VyIPCfmoA='); // "Ärger 🚀"Performance und Größenüberlegungen
Die 33 % Größenzunahme klingt harmlos, ist aber bei großen Datenmengen relevant. Ein 1-MB-Bild wird zu 1,37 MB Base64-Text. Wenn du das in ein JSON-Feld packst, kommen noch Escaping-Overhead und der JSON-Parser-Speicher dazu. Bei einer API, die viele Bilder überträgt, summiert sich das schnell.
Für Dateien über 10 KB ist ein separater Binär-Upload (multipart/form-data) fast immer besser als Base64 in JSON. Du sparst Bandbreite, der Server kann die Datei direkt streamen, und der Client braucht weniger Speicher zum Parsen.
In Datenbanken: Speichere Binärdaten als BLOB oder BYTEA, nicht als Base64-String. Die Base64-Darstellung braucht 33 % mehr Speicher und muss bei jedem Lesen/Schreiben kodiert/dekodiert werden. Das kostet CPU-Zyklen und verlangsamt Abfragen.
Browser-Performance: Data-URIs blockieren den Parser, weil sie inline verarbeitet werden. Eine CSS-Datei mit 20 Base64-kodierten Icons kann das Rendering spürbar verzögern. Verwende stattdessen einen SVG-Sprite oder moderne Formate wie AVIF mit separatem Caching.
Base64-Varianten im Überblick
Standard Base64 (RFC 4648 §4): Alphabet A–Z, a–z, 0–9, +, /. Padding mit =. Verwendet in MIME, PEM-Dateien und den meisten generischen Bibliotheken.
Base64url (RFC 4648 §5): Ersetzt + durch - und / durch _. Optionales Padding. Pflicht für JWT, verwendet in URL-Parametern und Dateinamen. Wenn du Token oder IDs in URLs übergibst, ist Base64url die richtige Wahl.
Base32: Verwendet ein 32-Zeichen-Alphabet (A–Z, 2–7). Weniger effizient (60 % Overhead statt 33 %), aber case-insensitive und einfacher manuell einzutippen. Verwendet in TOTP-Secrets (Google Authenticator) und Onion-Adressen.
Es gibt auch exotische Varianten wie Base85 (verwendet in Git-Packfiles und Adobe PostScript), Base58 (Bitcoin-Adressen, vermeidet verwechselbare Zeichen wie 0/O und l/1) und Base62 (alphanumerisch ohne Sonderzeichen, beliebt für Short-URLs).
Sicherheitshinweise und typische Fehler
Der häufigste Fehler: Base64 als Sicherheitsmaßnahme einsetzen. Passwörter Base64-kodiert in der Datenbank speichern schützt vor nichts. Verwende bcrypt, scrypt oder Argon2 für Passwort-Hashing. Base64 ist umkehrbar — Hashing nicht.
Zweiter häufiger Fehler: Base64-kodierte Daten ohne Validierung dekodieren. Ein manipulierter Base64-String kann nach dem Dekodieren beliebige Bytes enthalten. Wenn du dekodierte Daten als Dateiname, SQL-Query oder HTML verwendest, hast du eine Injection-Schwachstelle.
In Logs und Fehlermeldungen: Base64-kodierte Tokens oder Credentials sehen harmlos aus, sind aber trivial dekodierbar. Behandle sie wie Klartext-Secrets — nicht loggen, nicht in Fehlermeldungen anzeigen, nicht in Git committen.
Padding-Oracle-Angriffe: In bestimmten kryptographischen Kontexten (CBC-Mode mit Base64-kodierten Ciphertexts) kann ein Angreifer durch systematisches Ändern des Paddings die Klartexte rekonstruieren. Das ist kein Base64-Problem an sich, aber Base64-kodierte Kryptodaten erfordern zusätzliche Integritätsprüfung (HMAC).