Base64 erklärt: wie Kodieren und Dekodieren wirklich funktionieren

Was Base64 wirklich ist

Base64 ist eine Art, beliebige Bytes mit nur 64 sicheren Zeichen zu schreiben. Das ist die ganze Idee. Es ist keine Verschlüsselung, keine Komprimierung und keine Prüfsumme. Es löst ein schmales Problem: Sie haben Binärdaten, und der Kanal, durch den sie müssen, nimmt nur Text an.

Dieser Kanal kann ein E-Mail-Body sein, ein JSON-Feld, eine URL, ein HTTP-Header, eine YAML-Konfiguration oder eine PEM-Datei. Schicken Sie rohe Bytes, und irgendetwas auf dem Weg beschädigt sie: ein Nullbyte kürzt eine Zeichenkette, ein 0x0D wird von einer Zeilenende-Umwandlung umgeschrieben, ein hohes Byte wird in einem anderen Zeichensatz neu gedeutet. Base64 umgeht all das, weil es nur Buchstaben, Ziffern und zwei Satzzeichen verwendet — und die überleben es alle, als Text behandelt zu werden.

Der Preis ist die Größe: die Ausgabe ist etwa ein Drittel größer als die Eingabe. Das ist der Handel, und er lohnt sich fast immer, denn die Alternative sind Daten, die beschädigt ankommen.

Wie aus drei Bytes vier Zeichen werden

Base64 arbeitet in Gruppen von drei Bytes. Drei Bytes sind 24 Bit, und 24 teilt sich glatt in vier Gruppen von sechs. Jede 6-Bit-Gruppe indiziert ein Alphabet aus 64 Zeichen, drei Bytes Eingabe ergeben also vier Zeichen Ausgabe.

Nehmen Sie die drei Bytes von Man:

M = 77 = 01001101, a = 97 = 01100001, n = 110 = 01101110

Die Bits aneinanderhängen und neu in Sechsergruppen zerlegen:

010011 010110 000101 101110 → 19, 22, 5, 46 → T, W, F, u

Man wird also zu TWFu. Vier Zeichen, kein Padding nötig, weil die drei Bytes exakt aufgingen. Dieses „exakt aufgehen“ ist genau das Thema des nächsten Abschnitts.

Die 64 Zeichen

Die Indizes 0–25 sind A–Z, 26–51 sind a–z, 52–61 sind 0–9, und 62 und 63 sind die beiden, die allen Ärger machen. Im Standard-Base64 sind das + und /.

Das Alphabet, und warum es zwei gibt

+ und / sind in einem E-Mail-Body völlig in Ordnung und in einer URL geradezu feindlich. / ist ein Pfadtrenner und + bedeutet in einem Query-String ein Leerzeichen — ein Base64-Wert, der in eine URL geklebt wird, kann also mit veränderten Bytes zurückkommen, ohne dass irgendwo ein Fehler auftritt.

Daher base64url, eine Variante, die die ersten 62 Zeichen behält und die letzten zwei austauscht: - für + und _ für /. Es ist die Kodierung der JSON Web Tokens — wer je einen JWT von Hand gelesen hat, hat base64url gelesen — und von allem anderen, das in einer URL oder einem Dateinamen reist.

Ansonsten sind die beiden Varianten identisch, und genau das macht ihr Vermischen gefährlich. Eine Zeichenkette ohne jedes +, /, - oder _ ist in beiden gültig und dekodiert gleich. Eine, die sie enthält, dekodiert zu anderen Bytes, je nachdem welche Variante der Decoder annimmt — meist ohne jede Fehlermeldung. Unser Base64-Encoder und -Decoder nennt genau deshalb das erkannte Alphabet.

Das Padding, und warum Decoder sich darüber streiten

Die Eingabe ist selten ein Vielfaches von drei Bytes. Ein übriges Byte ergibt zwei Zeichen, zwei übrige Bytes ergeben drei, und Standard-Base64 füllt die Gruppe mit = wieder auf vier auf:

• 3 Bytes → 4 Zeichen, kein Padding
• 2 Bytes → 3 Zeichen + =
• 1 Byte → 2 Zeichen + ==

Das Padding trägt keine Daten. Es existiert, damit ein Decoder, der einen aneinandergehängten Strom liest, weiß, wo ein kodierter Wert endet. Wer eine einzelne, alleinstehende Zeichenkette dekodiert, braucht es überhaupt nicht — weshalb base64url es normalerweise weglässt und = in einer URL ohnehin unpraktisch ist.

Das praktische Problem

Manche Decoder verlangen Padding und lehnen eine Zeichenkette ohne es rundheraus ab. Andere nehmen beides. Das ist der häufigste einzelne Grund, warum ein Token in einer Sprache funktioniert und in einer anderen mit einem knappen „invalid base64“ scheitert. Die Behebung heißt fast immer: Padding zurückgeben, also = anhängen, bis die Länge ein Vielfaches von vier ist. Ein Decoder, der beim Padding streng ist, ist nicht kaputt — und der Encoder, der es wegließ, auch nicht. Sie folgen verschiedenen Hälften derselben Spezifikation.

Base64 ist keine Verschlüsselung

Das verdient einen eigenen Abschnitt, weil der Fehler so verbreitet und so teuer ist. Base64 hat keinen Schlüssel. Es verbirgt nichts. Das Umkehren ist ein einziger Funktionsaufruf, in jeder Sprache verfügbar und auf jeder Seite wie dieser.

Das Musterbeispiel ist HTTP-Basic-Authentifizierung. Ein Authorization: Basic-Header ist nichts weiter als benutzer:passwort in Base64. Er sieht undurchsichtig aus, und darin liegt die Gefahr: Wer noch keinen dekodiert hat, liest ihn als „verschlüsselt“, während in Wahrheit jeder, der den Request sieht, die Zugangsdaten lesen kann. Deshalb ist Basic Auth nur über HTTPS akzeptabel — die Geheimhaltung liefert der Transport, die Kodierung liefert keine.

Dasselbe gilt für eine JWT-Payload, für einen Base64-Block in einer Konfigurationsdatei und für einen API-Key, den jemand vor dem Commit „verschleiert“ hat. Wenn zwischen einem Angreifer und Ihrem Geheimnis nur Base64 steht, steht zwischen einem Angreifer und Ihrem Geheimnis nichts. Unser Leitfaden zum Dekodieren und Debuggen von JSON Web Tokens geht genauer darauf ein, was das speziell für Tokens bedeutet.

Wo man Base64 tatsächlich begegnet

Hat man die Form einmal erkannt, sieht man sie überall:

• E-Mail-Anhänge. MIME transportiert Binärdaten so seit den frühen Neunzigern, auf 76 Zeichen pro Zeile umgebrochen.
• data: URIs. Ein kleines Bild, in CSS oder HTML eingebettet als data:image/png;base64,… — ein HTTP-Request gegen ein Drittel mehr Bytes getauscht.
• PEM-Dateien. Zertifikate und Schlüssel zwischen -----BEGIN…-Markern sind Base64 des darunterliegenden DER, auf 64 Zeichen umgebrochen.
• JWTs. Header und Payload sind base64url-kodiertes JSON; die Signatur ist base64url roher Bytes.
• Basic Auth und manche API-Zugangsdaten. Wie oben, mit demselben Vorbehalt.
• Binärdaten in JSON. JSON hat keinen Byte-Typ, also reisen Bytes als Base64-Zeichenkette.

Warum manches Base64 Zeilenumbrüche hat

MIME bricht bei 76 Zeichen um, PEM bei 64, weil die Formate, in denen sie leben, älter als lange Zeilen sind. Diese Umbrüche gehören nicht zu den Daten, und ein Decoder muss sie ignorieren. Die meisten tun das; einige nicht, und darum scheitert das Einfügen eines umgebrochenen PEM-Bodys in einen strengen Decoder manchmal, bis man die Zeilenumbrüche entfernt.

Der Größenaufwand, und wann er zählt

Vier Zeichen pro drei Bytes ist eine 4/3-Aufblähung — etwa 33 % — vor Padding und Zeilenumbrüchen. Für einen einmaligen Konfigurationswert ist das belanglos. Für alles auf einem heißen Pfad nicht.

Ein 10 KB großes Bild als data: URI kostet rund 13,3 KB HTML und kann, anders als ein echtes Bild, nicht separat gecacht oder verzögert geladen werden. Ein Token, das bei jedem API-Aufruf mitgeht, trägt seinen Aufwand bei jedem Request. Und Komprimierung rettet Sie nicht: Base64-Ausgabe komprimiert weit schlechter als die ursprünglichen Bytes, weil die Kodierung die Muster auf Byte-Ebene zerstört, nach denen ein Kompressor sucht. Erst komprimieren, dann kodieren — niemals umgekehrt.

Text kodieren heißt Bytes kodieren

Base64 kodiert Bytes. Es kennt keine Zeichen, also ist „kodiere diese Zeichenkette in Base64“ immer die Kurzform für „mach aus dieser Zeichenkette Bytes und kodiere dann diese Bytes“. Der Schritt dazwischen ist die Stelle, an der es schiefgeht, denn er braucht eine Zeichenkodierung — und die Spezifikation wählt keine für Sie.

In der Praxis lautet die Antwort UTF-8, und moderne APIs nehmen sie als Standard. Kodiert aber eine Seite den Text als UTF-16 oder Latin-1 und dekodiert die andere als UTF-8, dann ist das Base64 völlig gültig und der Text, der herauskommt, ist Buchstabensalat. Das Erkennungszeichen: Nicht-ASCII-Zeichen überleben schlecht, reines ASCII überlebt tadellos — denn ASCII ist eine Teilmenge von UTF-8.

Der Hin-und-zurück-Test

Wenn Sie unsicher sind, ob eine Verarbeitungskette Text korrekt behandelt: kodieren Sie eine Zeichenkette mit einem Akzent und einem nichtlateinischen Zeichen, dekodieren Sie sie wieder und vergleichen Sie. Alles, was José oder ein Emoji verstümmelt, verliert irgendwo in der Byte-Umwandlung Information — nicht im Base64 selbst.

Wenn das Dekodieren schiefgeht

Vier Diagnosen decken fast alle Fälle ab:

• „Ungültiges Zeichen“. Etwas außerhalb des Alphabets ist hineingeraten — meist ein verirrtes Leerzeichen, ein mit der Zeichenkette kopiertes Anführungszeichen oder ein vorne stehengebliebenes data:image/png;base64,.
• „Ungültige Länge“. Nach dem Entfernen von Leerraum ergibt die Länge modulo vier 1, was kein gültiges Base64 erzeugen kann. Unterwegs ist ein Zeichen verloren gegangen.
• Es dekodiert, aber zu Buchstabensalat. Entweder passen die Alphabete nicht zusammen (base64url als Standard dekodiert oder umgekehrt), oder die Textkodierung passt nicht, wie oben beschrieben.
• Es dekodiert zu Bytes, die gar kein Text sind. Das ist kein Fehler. Viel Base64 enthält ein Bild, einen Schlüssel oder eine serialisierte Struktur; ein guter Decoder zeigt Ihnen eine Hex-Ansicht, statt zu behaupten, das Ergebnis sei eine Zeichenkette.

Diese Punkte in dieser Reihenfolge durchzugehen — Zeichen, Länge, Alphabet, Kodierung — löst fast alles. Und wenn ein Wert sich einfach nirgends dekodieren lässt, ist die wahrscheinlichste Erklärung die langweiligste: er war abgeschnitten. Base64 hat keine Integritätsprüfung, also sieht eine Zeichenkette, die ihr Ende verloren hat, genau aus wie eine, die nie eines hatte.

Verwandte Tools und Leitfäden:

• Base64-Encoder & -Decoder – Text in Base64 kodieren oder zurück, mit URL-safe-Ausgabe und korrektem UTF-8.
• JWT Decoder – Dekodieren Sie ein JSON Web Token und lesen Sie Header, Payload, Claims und Ablauf.
• JWT erklärt: JSON Web Tokens dekodieren und debuggen – Was in einem JSON Web Token steckt

Häufige Fragen