Base64 erklärt: Encoder und Decoder mit Byte-Aufschlüsselung

Wenn du in einem Konfig-File cGFzc3dvcmQ6IHN1cGVyc2VjcmV0 siehst oder ein API-Token mit eyJ startet, schaust du auf Base64. Es ist keine Verschlüsselung und kein Protokoll, sondern eine reine Übersetzungsschicht: beliebige Bytes werden in 64 sichere ASCII-Zeichen gepackt, damit sie durch Text-Kanäle wie URLs, JSON-Strings oder E-Mail-Header passen. Der Encoder unten zeigt die UTF-8-Bytes deiner Eingabe in 3-Byte-Gruppen, daneben den passenden 4-Zeichen-Block der Ausgabe.

Was ist Base64 und warum sieht es so aus?

Base64 verpackt drei Bytes (24 Bits) in vier Zeichen aus einem 64er-Alphabet (A-Z, a-z, 0-9, +, /). Dadurch wächst die Größe um etwa 33 Prozent - der Preis dafür, dass das Ergebnis nur aus harmlosen ASCII-Zeichen besteht und Binärdaten durch Systeme transportieren kann, die sonst nur Text durchlassen.

Die Ergebnisansicht oben zerlegt deine Eingabe in vier Kategorien: ASCII-Bytes grau, UTF-8-Lead-Bytes orange, UTF-8-Continuation-Bytes gelb, Padding = violett. Jede 3-Byte-Gruppe links bekommt einen 4-Zeichen-Block rechts. Bei hello (5 Bytes) entstehen zwei Blöcke - der zweite ist mit einem = aufgefüllt. Bei München siehst du, wie Mü als drei Bytes (4D C3 BC) zum Block TcO8 wird.

Direkt unter den Chips läuft eine Bit-Leiste mit: drei 8-Bit-Bytes auf der Eingabe-Seite, vier 6-Bit-Sextets auf der Ausgabe-Seite. Beide Seiten tragen exakt 24 Bit, nur anders zerschnitten. Markierst du einen Block, springt die Leiste auf diesen Quanten - so siehst du Byte für Byte, wie aus 4D C3 BC (also 01001101 11000011 10111100) die Sextets 19 28 14 60 werden, die im Standard-Alphabet T c O 8 heißen.

Wann triffst du auf Base64?

Base64 ist überall dort, wo Bytes durch Textkanäle müssen. Nicht nur Entwickler lesen das. Power-User, Sysadmins und Studierende stoßen genauso darauf, meist ohne zu wissen, dass es eine Übersetzung ist und kein Geheimcode.

• Kubernetes-Secrets speichern data-Werte in der YAML-Datei Base64-kodiert (echo -n "passwort" | base64 ergibt cGFzc3dvcmQ=). stringData ist die Klartext-Alternative.
• Data-URIs in HTML wie data:image/png;base64,iVBORw0KG... betten Bilder direkt in das Markup ein.
• JWT-Tokens bestehen aus drei Base64-url-safe-Teilen: Header, Payload, Signatur. → JWT-Header dekodieren
• E-Mail-Anhänge wandern seit den 90ern als Base64 durch SMTP, weil das Protokoll nur 7-Bit-ASCII garantiert.
• Browser-APIs wie FileReader.readAsDataURL liefern Base64. JWK-Felder aus crypto.subtle.exportKey("jwk", ...) nutzen Base64url.

Brauchst du die Bytes als Hex-Liste statt als Base64 - etwa um sie gegen xxd, einen Hex-Viewer oder die Ausgabe von openssl zu halten - liefert die Aktion "Hex kopieren" die Sequenz fertig zum Einfügen.

Standard oder URL-safe - welche Variante passt?

Der Variant-Schalter oben entscheidet zwischen den zwei Alphabeten aus RFC 4648. Standard (§4) nutzt + und /. Beide sind in URLs Sonderzeichen und werden bei ?q=cGFzc/+= zu cGFzc%2F%2B%3D - lesbar wird das nicht. URL-safe (§5) ersetzt + durch -, / durch _ und lässt das Padding-= meist weg, sodass die Zeichenkette ohne weiteres in einer URL, in einem Dateinamen oder in einem Cookie-Wert stehen darf.

Im Zweifel Standard. Wechsle erst dann auf URL-safe, wenn du den Base64-String in eine URL oder einen Dateinamen schreibst.

Was bedeutet das = am Ende?

Padding-= füllt den letzten Block auf vier Zeichen auf. Base64 nimmt drei Bytes auf einmal. Hat dein Input ein Vielfaches von drei Bytes, gibt es kein =. Bleibt am Ende ein Byte übrig, kommen zwei =. Bleiben zwei Bytes übrig, kommt ein =.

1. hello (5 Bytes) → ein voller 3-Byte-Block plus 2 Bytes übrig → aGVsbG8= (→ Beispiel laden).
2. hi (2 Bytes) → 2 Bytes übrig → aGk=.
3. Foo (3 Bytes) → exakt aufgegangen → Rm9v, kein Padding.
4. a (1 Byte) → ein Byte übrig → YQ==.

Das Padding ist nicht nur Kosmetik. Decoder können daraus die exakte Byte-Anzahl ableiten, ohne den Rest zu interpretieren. Die URL-safe-Variante lässt das Padding meist weg, weil die Länge auch implizit ableitbar ist - der Decoder oben akzeptiert beides.

Warum ist btoa() bei Umlauten tückisch?

btoa(string) ist eine Browser-API aus den 90ern. Sie erwartet einen Byte-String, also Zeichen mit Codewerten von 0x00 bis 0xFF. Ein ü (U+00FC) liegt zwar in diesem Bereich, deshalb wirft btoa("München") nicht. Das Ergebnis ist aber TfxuY2hlbg==, weil ü als einzelnes Byte 0xFC behandelt wird. Die UTF-8-Form, die APIs normalerweise erwarten, ist TcO8bmNoZW4=.

Sobald ein Emoji oder ein chinesisches Zeichen kommt, wirft btoa InvalidCharacterError, weil diese Zeichen nicht in ein einzelnes Byte passen. Der Encoder oben löst beides, indem er über TextEncoder geht: erst Text in UTF-8-Bytes zerlegen, dann String.fromCharCode(...bytes) aufrufen, dann btoa. Dieselbe Logik gilt fürs Dekodieren: atob liefert eine Byte-Sequenz, die TextDecoder als UTF-8-Text zurück übersetzt. Bei München siehst du in der Ergebnisansicht oben den Sprung von 7 Zeichen auf 8 Bytes - das ü belegt zwei davon.

Häufige Fragen

Was ist Base64 und warum gibt es das?

Base64 ist eine Kodierung, die beliebige Bytes in nur 64 sichere ASCII-Zeichen verpackt (A-Z, a-z, 0-9, +, /). Ursprung sind E-Mails, die jahrzehntelang nur 7-Bit-ASCII transportieren konnten. Heute taucht Base64 in Data-URIs, JWT-Tokens, Kubernetes-Secrets und überall dort auf, wo Binärdaten durch einen Text-Kanal müssen.

Was bedeutet das = am Ende einer Base64-Zeichenkette?

Das = ist Padding. Base64 verpackt drei Bytes in vier Zeichen. Wenn die Eingabe nicht durch drei teilbar ist, wird der letzte Block mit = aufgefüllt. Ein = heißt zwei Daten-Bytes im letzten Block, zwei = heißen ein Daten-Byte. Die URL-safe-Variante lässt das Padding meist weg.

Warum produziert btoa() bei Umlauten Müll?

btoa(string) erwartet einen Byte-String. Umlaute wie ü werden dann als Latin-1-Byte behandelt, Emoji und viele andere Zeichen werfen einen Fehler. Der Tool-Code geht über TextEncoder und produziert die UTF-8-Base64-Form, die Server und APIs erwarten. Auch der URL-Encoder benutzt UTF-8 als Zwischenschritt.

Ist Base64 eine Verschlüsselung?

Nein. Base64 ist eine Kodierung, keine Verschlüsselung. Jeder mit dem String und dem Decoder erhält den Klartext zurück. Wenn du etwas geheim halten musst, brauchst du Verschlüsselung (AES, RSA, libsodium).

Wann brauche ich Base64 in einer URL?

Wann immer Bytes durch eine URL müssen, ohne dass sie zerstört werden. JWT-Tokens, OAuth-State-Parameter, Webhook-Signaturen, manchmal Bild-Hashes in Pfaden. Wechsle dann auf die URL-safe-Variante - sonst landest du am Ende mit doppelter Kodierung. Mehr zur Mechanik im URL-Encoder.