Base64-Kodierung — was es ist, wann man es verwendet und wann nicht

Base64 ist eines dieser Formate, das jeder Entwickler verwendet hat, aber wenige können es erklären, ohne zu pausieren. Es sieht wie zufällige Zeichen aus. Es macht Daten größer. Und doch ist es das Rückgrat von E-Mail-Anhängen, JWT-Payloads, Inline-Bildern in CSS und Dutzenden anderer Protokolle, die binäre Daten über reine Textkanäle bewegen müssen.

Die kurze Version: Base64 kodiert beliebige binäre Daten als druckbare ASCII-Zeichen. Die lange Version umfasst ein 64-Zeichen-Alphabet, Auffüllregeln und einige Varianten, die Leute in der Produktion hereinlegen.

Warum Base64 existiert

Viele Systeme wurden nur für den Texttransport entworfen — E-Mail (SMTP), URLs, XML, JSON. Wenn Sie eine binäre Datei durch eine dieser Leitungen senden möchten, brauchen Sie eine Möglichkeit, Bytes als Zeichen darzustellen. Base64 löst dies, indem es alle 3 Bytes der Eingabe auf 4 Zeichen der Ausgabe abbildet, wobei nur Zeichen verwendet werden, die in praktisch jedem Textprotokoll sicher sind.

Der Kompromiss: Base64 vergrößert die Daten um etwa 33%. Ein 1KB-Bild wird zu etwa 1,3KB Text. Für die meisten Anwendungsfälle ist das in Ordnung. Für High-Throughput-Systeme ist es wichtig, und Sie sehen Alternativen wie Base85 oder rohe Binärprotokolle.

Die 64 Zeichen

Das Alphabet ist:

A-Z  (26 Zeichen)
a-z  (26 Zeichen)
0-9  (10 Zeichen)
+ /  (2 Zeichen)

Das sind 64 Zeichen insgesamt, daher der Name. Das Zeichen = wird zum Auffüllen verwendet, wenn die Eingabelänge kein Vielfaches von 3 Bytes ist.

Jedes Zeichen im Alphabet ist druckbares ASCII, was bedeutet, dass Base64-Ausgabe durch E-Mails reisen, in JSON-Zeichenstrings erscheinen, innerhalb von HTML-Attributen sitzen und Systeme überleben kann, die rohe Binärdaten verfälschen könnten.

Wie die Kodierung funktioniert

Nehmen Sie drei Bytes Eingabe. Jedes Byte hat 8 Bits, also haben Sie insgesamt 24 Bits. Base64 teilt diese 24 Bits in vier 6-Bit-Gruppen. Jede 6-Bit-Gruppe wird einem Zeichen im Alphabet zugeordnet:

• 000000 → A
• 000001 → B
• …
• 111111 → z

Das ist alles. Die Kodierung ist eine einfache Bit-Ebene-Transformation ohne Schlüssel, Salz oder Geheimnis. Jeder kann Base64 dekodieren, indem er die Nachschlagetabelle umkehrt.

Auffüllung

Wenn die Eingabelänge kein Vielfaches von 3 ist, füllt die Auffüllung die Lücke:

• 1 Byte übrig → 2 Base64-Zeichen + ==
• 2 Bytes übrig → 3 Base64-Zeichen + =
• 0 Bytes übrig → keine Auffüllung

Die Auffüllungszeichen tragen keine Daten. Sie existieren, damit die Ausgabelänge immer ein Vielfaches von 4 ist, was viele Parser erwarten.

Varianten

Nicht alles Base64 ist identisch:

• Standard-Base64 (A-Za-z+/=) — die Standardeinstellung, verwendet in MIME-E-Mails und den meisten Protokollen.
• URL-sicheres Base64 (A-Za-z-_) — ersetzt + durch - und / durch _, entfernt die Auffüllung. Verwendet in JWTs, URL-Parametern und Dateinamen.
• Base64 ohne Auffüllung — einige Systeme lassen die =-Zeichen weg. Die Ausgabe ist kürzer, aber einige Parser scheitern daran.

Wenn Sie ein JWT oder ein Data URI debuggen und die Dekodierung fehlschlägt, ist das Erste zu prüfen, ob der Kodierer URL-sicheres Base64 oder Standard-Base64 verwendet hat. Ein - in der Mitte dessen, was Sie als Standard-Base64-Zeichenkette erwartet haben, ist der Hinweis.

Wo Entwickler Base64 tatsächlich begegnen

E-Mail-Anhänge. MIME (RFC 2045) verwendet Base64, um binäre Anhänge zu kodieren. Wenn Sie jemals eine .eml-Datei mit langen Zeichenketten zufälliger Zeichen gesehen haben, ist das Base64-kodierter Inhalt.

JWT-Payloads. Die drei Teile eines JWT (Header, Payload, Signatur) sind jeweils URL-sicher base64-kodiert. Wenn Sie ein JWT dekodieren, kehren Sie die Base64url-Kodierung auf jedem Segment um.

Data URIs. data:image/png;base64,iVBOR... ermöglicht es, ein Bild direkt in HTML oder CSS einzubetten. Die Bildbytes sind Base64-kodiert, damit sie in einem Textattribut erscheinen können.

APIs. Manche APIs akzeptieren oder liefern Base64-kodierte Binärdateien (Datei-Uploads, Bildverarbeitung, kryptographische Signaturen). Es ist weniger verbreitet, seit die meisten APIs Multipart-Formulardaten unterstützen, aber es kommt noch vor.

Einbettungen. Maschinelles-Lern-Modelle speichern Embeddings manchmal als Base64-Zeichenketten in JSON. Es ist nicht ideal für die Leistung, aber bequem für den Transport.

Wann Base64 NICHT verwenden

Nicht zur Verschlüsselung verwenden. Base64 ist eine Kodierung, nicht Verschlüsselung. Jeder kann es dekodieren. Wenn Sie sensible Daten in Base64 packen, verbergen Sie sie nur, schützen sie nicht.

Nicht zur Komprimierung verwenden. Base64 macht Daten größer, nicht kleiner. Wenn Sie bereits komprimierte Daten (wie eine .gz-Datei) in Base64 kodieren, fügen Sie Overhead ohne Nutzen hinzu.

Nicht in leistungskritischen Pfaden verwenden. Die Kodierung/Dekodierung fügt CPU-Zeit hinzu und vergrößert die Nutzlast. Für hochfrequente interne APIs verwenden Sie binäre Protokolle (protobuf, msgpack) stattdessen.

Variante nicht vergessen. Wenn Sie Base64 für eine URL oder ein JWT erzeugen, verwenden Sie URL-sicheres Base64. Wenn Sie für E-Mail oder allgemeinen Transport erzeugen, verwenden Sie Standard-Base64. Das Vermischen verursacht stille Datenkorruption.

Schnellreferenz

Szenario	Variante	Auffüllung
JWT	URL-sicher	Nein
E-Mail / MIME	Standard	Ja
Data URI	Standard	Optional
URL-Parameter	URL-sicher	Nein
Allgemeiner Transport	Standard	Ja

Ausprobieren

Wenn Sie einen Base64-String dekodieren oder binäre Daten kodieren müssen, verwenden Sie ein browserbasiertes Tool, damit die Konvertierung lokal erfolgt — Ihre Daten werden für etwas so Einfaches nicht an einen Server gesendet.