Was Base64 wirklich ist: Warum ein Bild zu einer Zeichenkette wird

Wenn Sie je den Quelltext einer Webseite angesehen haben, haben Sie wahrscheinlich ein <img>-Tag gesehen, dessen src kein Dateipfad ist, sondern ein langer Lauf von Buchstaben, Ziffern, Pluszeichen und Schrägstrichen — oft beginnend mit iVBORw0KGgo und manchmal endend auf =. Das ist Base64: ein Bild, „übersetzt“ in reinen Text. Warum sollte jemand das tun, und wie entsteht die Zeichenkette? Dieser Artikel beantwortet beide Fragen von Grund auf.

Das Grundproblem: Textkanäle, Binärdaten

Alles auf einem Computer sind Bytes — je 8 Bits, Werte 0 bis 255. Doch viele Transportsysteme wurden für Text entworfen. Frühe E-Mail (SMTP) garantierte nur, dass 7-Bit-ASCII die Reise übersteht, und Formate wie JSON, XML und URLs reservieren Zeichen, die nicht roh erscheinen dürfen. Werfen Sie beliebige Binärbytes in diese Kanäle, werden die Daten irgendwo unterwegs verstümmelt oder abgeschnitten.

Die Antwort von Base64 ist einfach: Stellen Sie beliebige Binärdaten nur mit 64 druckbaren Zeichen dar, die jedes Textsystem unangetastet durchlässt. Einmal kodiert, kann ein Bild, ein Zertifikat oder ein kryptografischer Schlüssel in einem Textprotokoll mitreisen, ohne Furcht.

Das 64-Zeichen-Alphabet

Das Standardalphabet (RFC 4648) ist:

Indexbereich	Zeichen
0–25	A–Z
26–51	a–z
52–61	0–9
62	+
63	/

Jedes Zeichen steht für einen Wert von 0 bis 63 — genau 6 Bits Information (2⁶ = 64). Diese eine Tatsache ist der Schlüssel zu allem Weiteren bei Base64: Jedes Zeichen trägt sechs Bits der Originaldaten.

Der Kodierungsprozess: 3 Bytes werden 4 Zeichen

Ein Byte ist 8 Bits; ein Base64-Zeichen trägt 6. Das kleinste gemeinsame Vielfache von 8 und 6 ist 24, die Kodierung arbeitet also in Gruppen von 3 Bytes (24 Bits), die in vier 6-Bit-Blöcke geteilt werden, und jeder Block wird im Alphabet nachgeschlagen, um ein Zeichen zu erzeugen. Daher „3 Bytes werden 4 Zeichen“.

Lassen Sie uns die Zeichenkette Man durch die ganze Pipeline schicken (das klassische RFC-4648-Beispiel):

1. Die ASCII-Codes für M, a, n sind 77, 97, 110.
2. Binär aneinandergereiht: 01001101 01100001 01101110 — 24 Bits.
3. In 6-Bit-Blöcke geteilt: 010011, 010110, 000101, 101110.
4. Als Dezimalzahlen: 19, 22, 5, 46.
5. Im Alphabet nachgeschlagen: 19→T, 22→W, 5→F, 46→u.

Man kodiert also zu TWFu. Fügen Sie es in einen Base64-Encoder/Decoder ein, und Sie erhalten genau das. Das Dekodieren ist das Spiegelbild: jedes Zeichen zurück auf 6 Bits abbilden, aneinanderreihen und wieder in 8-Bit-Bytes teilen.

Warum die Größe um etwa 33 % wächst

Die Arithmetik ist eine Zeile: 3 Bytes Eingabe werden 4 Zeichen Ausgabe, und jedes Zeichen kostet ein Byte Text, also werden 3 Bytes zu 4 Bytes. Vier Drittel ist rund 1,333 — ein Aufschlag von 33 %, immer. Ein 300-KB-Bild wird zu etwa 400 KB Base64-Text.

Das ist der Hauptgrund, warum das Inlining großer Bilder als Base64 abgelehnt wird: Über die Aufblähung hinaus muss der Browser das gesamte HTML-Dokument herunterladen, bevor er überhaupt mit dem Dekodieren beginnen kann, wodurch sowohl paralleles Laden als auch separates Caching verloren gehen. Inline-Base64 sinnvoll ist für winzige Assets — Icons und Platzhalter von ein paar Kilobyte.

= ist Padding, keine Daten

Die Eingabelänge ist nicht immer ein Vielfaches von 3. Bleibt ein Byte übrig (8 Bits), können Sie zwei 6-Bit-Blöcke formen (12 Bits, der letzte vier mit Nullen gefüllt), was zwei Zeichen gefolgt von == erzeugt. Bleiben zwei Bytes übrig, erhalten Sie drei Zeichen gefolgt von einem =. Eine Base64-Zeichenkette endet also auf null, ein oder zwei =-Zeichen — nie mehr.

Zwei schnelle Beispiele: M (1 Byte) kodiert zu TQ==, und Ma (2 Bytes) kodiert zu TWE=. Das = ist rein ein Platzhalter, der dem Decoder sagt: „Die letzte Gruppe war kurz.“ Beachten Sie, dass manche Systeme das Padding ganz entfernen — JWTs tun das —, eine häufige Ursache für „warum lässt sich das nicht dekodieren“: Sie müssen die =-Zeichen selbst wieder anfügen.

Die URL-sichere Variante

Die + und / des Standardalphabets haben in URLs besondere Bedeutungen (+ wird in Query-Strings als Leerzeichen interpretiert), rohes Base64 kann also nicht sicher in einen Link. RFC 4648 definiert daher auch Base64url: - ersetzt +, _ ersetzt /, und das abschließende = entfällt meist. JSON Web Tokens nutzen es — jedes der drei Segmente in einem eyJhbGci...-Token ist Base64url.

Praktischer Tipp: Lässt sich eine Base64-Zeichenkette nicht dekodieren, prüfen Sie, ob sie - oder _ enthält. Wenn ja, ist es die URL-sichere Variante — tauschen Sie diese zwei Zeichen vor dem Dekodieren zurück.

Base64 ist keine Verschlüsselung — und auch keine Kompression

Das ist das Missverständnis, das am meisten zählt. Base64 ist eine Kodierung, keine Verschlüsselung: Das Schema ist öffentlich, jeder kann es in Millisekunden umkehren, und es gibt keinen Schlüssel. Ein Passwort oder einen API-Schlüssel mit Base64 zu „verschlüsseln“, bevor man es speichert, ist gleichbedeutend damit, es im Klartext zu speichern — das Erste, was ein Angreifer mit einer verdächtigen =-terminierten Zeichenkette tut, ist sie zu dekodieren.

Es komprimiert auch nichts; wie oben berechnet, macht es Daten um ein Drittel größer. Base64 zu erkennen ist einfach: Die Länge ist ein Vielfaches von 4, und jedes Zeichen fällt in A-Za-z0-9+/ plus optionales abschließendes =. Um es von Hand zu klären, werfen Sie die verdächtige Zeichenkette in einen Encoder/Decoder — ist es Base64, erscheint der Originalinhalt sofort.

Data-URIs: der klassische Anwendungsfall

Base64s sichtbarstes Habitat ist die Data-URI, mit dem Format:

data:[<media type>][;base64],<data>

Ein kleines PNG-Icon direkt in HTML einzubetten sieht so aus:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." alt="icon">

Und derselbe Trick funktioniert in CSS:

.logo {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0...");
}

Der Gewinn ist eine HTTP-Anfrage weniger: Das Bild kommt mit dem HTML oder CSS selbst, was sich für kleine, häufig genutzte Assets lohnt. Die Kosten sind die bereits behandelten — 33 % mehr Bytes und kein unabhängiges Browser-Caching. Die gängige Faustregel ist, nur Assets unter ein paar Kilobyte inline einzubetten. Die Konvertierung selbst ist trivial: Ein Bild-zu-Base64-Konverter nimmt ein hochgeladenes Bild und reicht Ihnen die vollständige Data-URI, mit Präfix data:image/png;base64, und allem drum und dran.

Über Data-URIs hinaus taucht Base64 überall auf: E-Mail-Anhänge (MIME), Binärfelder in APIs (Zertifikate, Signaturen, Thumbnails), Kubernetes-Secrets und die erwähnten JWTs. Haben Sie den Kern „3 Bytes werden 4 Zeichen“ einmal verstanden, ist dieser lange Zeichenlauf nicht mehr mysteriös — Sie wissen genau, was er dort tut, und wie Sie ihn selbst zurückverwandeln.