Entwicklung · 3 Min. Lesezeit ·

Base64 erklärt: Wofür es da ist und warum es nicht verschlüsselt

Base64 steckt in E-Mails, Data-URIs, API-Headern und JWTs. Wie es funktioniert, warum Daten ein Drittel größer werden und warum es nie etwas verbirgt.

Base64 ist in Software allgegenwärtig: E-Mail-Anhänge, in CSS eingebettete Bilder, der Authorization-Header von HTTP Basic Auth und die Teile eines JWT. Es hat genau eine Aufgabe: beliebige Daten, auch binäre Bytes, nur mit sicheren Textzeichen darzustellen.

So funktioniert es

Base64 nimmt die Daten in Dreiergruppen von Bytes (24 Bit) und teilt sie in vier Gruppen zu 6 Bit. Jede Gruppe ist eine Zahl von 0 bis 63, die einem von 64 Zeichen entspricht: A-Z, a-z, 0-9, + und /. Lässt sich die Eingabe nicht in Dreiergruppen teilen, füllen =-Zeichen das Ende auf.

Text    M        a        n
Bytes   01001101 01100001 01101110
6 Bit   010011 010110 000101 101110
Base64  T      W      F      u       →  TWFu

Warum es das gibt

Viele ältere Systeme, allen voran E-Mail, wurden für Text gebaut und konnten beliebige Bytes beschädigen. Base64 macht aus allem normale Zeichen, die solche Kanäle unverändert passieren. Der Preis ist die Größe: Aus 3 Bytes werden 4 Zeichen, kodierte Daten sind also etwa 33 % größer.

Es ist keine Verschlüsselung

Es gibt keinen Schlüssel. Jeder kann Base64 sofort dekodieren, also verbirgt es nichts. Ein Passwort in einem Basic-Auth-Header (dXNlcjpwYXNz ist einfach user:pass) liegt genauso offen wie Klartext. Schütze Geheimnisse mit HTTPS und echter Verschlüsselung und betrachte Base64 nie als Sicherheitsmaßnahme.

Varianten, die dir begegnen

Base64url ersetzt + und / durch - und _ und lässt meist das Auffüllen weg, sodass das Ergebnis in URLs und Dateinamen sicher ist; JWTs nutzen es. Data-URIs betten kodierte Daten direkt ein, etwa data:image/png;base64,iVBOR…, was bei winzigen Bildern eine Anfrage spart, größere aber schwerer macht.

Die Größe in Zahlen

Die kodierte Länge beträgt 4 × ceil(n / 3) Zeichen für n Bytes, der Aufschlag liegt also bei etwa 33 %, plus Zeilenumbrüche, falls der Encoder sie einfügt.

Bild mit 100 KB   →  etwa 133 KB Base64
Anhang mit 1 MB   →  etwa 1,33 MB (plus Zeilenumbrüche in E-Mails)

Warum das Dekodieren scheitert

  • Fehlendes Padding: Manche Systeme lassen die abschließenden =-Zeichen weg, und strenge Decoder lehnen die Eingabe dann ab. Füge = an, bis die Länge durch 4 teilbar ist.
  • Das falsche Alphabet: Base64url verwendet - und _ statt + und /. Dekodiere es mit einem Base64url-Decoder oder tausche die Zeichen vorher zurück.
  • Zeilenumbrüche und Leerzeichen: E-Mail (MIME) bricht Base64 nach 76 Zeichen um. Die meisten Decoder ignorieren das, aber nicht alle.
  • Text in der falschen Kodierung: Dekodieren liefert Bytes. Waren sie UTF-8-Text, werden aber als Latin-1 gelesen, werden Umlaute und Hebräisch zu Zeichensalat.

Die btoa-Falle in JavaScript

Die eingebaute Browserfunktion btoa() akzeptiert nur Zeichen aus Latin-1 und wirft bei Hebräisch, Chinesisch oder Emojis einen Fehler. Wandle den Text zuerst in UTF-8-Bytes um, zum Beispiel mit TextEncoder, und erst dann in Base64.

Wann es passt und wann nicht

Base64 ist das richtige Werkzeug, wenn Binärdaten durch einen Kanal für Text müssen: JSON- und XML-Nutzdaten, E-Mail, Data-URIs und HTTP-Header. Es ist das falsche Werkzeug, um Daten zu verstecken, um sie zu verkleinern (sie werden immer größer) und um große Dateien in einer Datenbank abzulegen, wo eine Binärspalte oder ein Objektspeicher kleiner und schneller ist. Wenn die Gegenseite rohe Bytes annimmt, schick rohe Bytes.

Probier es aus

Der Base64-Encoder von 4Dev wandelt Text schon beim Tippen in Base64 um. Er nutzt UTF-8, sodass Umlaute, ß, Emoji und jeder andere nicht englische Text korrekt kodiert werden. Für den umgekehrten Weg gibt es den Base64-Decoder.

Base64-Encoder öffnen

LinkedInXFacebook