Base64-Encoding erklärt: Warum, wann und die häufigen Varianten

Base64 ist überall – E-Mail-Anhänge, JWT-Tokens, Data-URIs, PEM-Blöcke von Zertifikaten, OAuth-Client- Secrets, Nutzlasten von Push-Benachrichtigungen – und fast niemand hält inne, um zu fragen, was es eigentlich tut. Es erfüllt eine bestimmte Aufgabe, hat drei nahezu identische Varianten, und die Unterschiede zwischen ihnen verursachen die meisten Bugs.

Welches Problem Base64 löst

Viele Transportkanäle sind für Text ausgelegt, nicht für beliebige Bytes. E-Mail-Texte mussten historisch druckbares ASCII sein. URLs dürfen keine rohen Steuerzeichen oder Leerzeichen enthalten. JSON- Zeichenketten müssen gültiges Unicode sein. Wenn Sie ein PNG in einem dieser Kanäle senden wollen, brechen die rohen Bytes den Kanal.

Base64 nimmt eine beliebige Bytefolge und drückt sie nur mit 64 sicheren Zeichen plus optionalem Padding neu aus. Das Ergebnis passt überall dorthin, wo Text passt, und ein Decoder stellt die ursprünglichen Bytes exakt wieder her. Es gibt keinen Verlust, keine Kompression und keine Sicherheit – nur eine Formatänderung.

Das Alphabet

Standard-Base64 (RFC 4648 §4) verwendet insgesamt 65 Zeichen:

• A–Z — Werte 0–25
• a–z — Werte 26–51
• 0–9 — Werte 52–61
• + — Wert 62
• / — Wert 63
• = — Padding, kein Wert

Jedes Zeichen trägt 6 Bit (weil 2⁶ = 64). Drei Eingabe-Bytes (24 Bit) bilden vier Ausgabe-Zeichen (24 Bit) ab. Wenn die Eingabe kein Vielfaches von 3 Bytes ist, füllt der Encoder rechts mit Nullen auf und gibt für jeden Padding-Schritt ein =aus. Ein übrig gebliebenes Byte wird zu “zwei Zeichen + ==”; zwei übrig gebliebene Bytes werden zu “drei Zeichen + =”.

Warum die Ausgabe 33 % größer ist

4 Ausgabe-Zeichen tragen nur das, was 3 Eingabe-Bytes trugen, also beträgt die Aufblähung genau 4/3 = 1,333…, also 33,3 % mehr. Padding fügt bei kurzen Eingaben eine winzige Menge mehr hinzu. Eine 1 MB große Binärdatei wird zu einer 1,33 MB großen Base64-Zeichenkette. Das ist der Preis für textsicheren Transport; wenn Sie ihn sich nicht leisten können, können Sie Base64 nicht verwenden.

Probieren Sie unseren Base64-Encoder / -Decoder mit einer Beispieleingabe aus – Sie sehen das Größenverhältnis neben dem Ergebnis angezeigt.

Die drei Varianten, denen Sie begegnen werden

Standard-Base64 (RFC 4648 §4)

Das Original. Das Alphabet enthält + und /, das Padding mit =ist erforderlich. Verwendet von PEM-Dateien (TLS- Zertifikate, SSH-Schlüssel), XML Signature, SOAP- Anhängen und dem Authorization: Basic HTTP-Header.

Base64url (RFC 4648 §5)

URL- und dateinamensicher. Ersetzt + durch - und / durch _. Padding ist laut Spezifikation technisch optional, wird in der Praxis aber fast immer weggelassen. Das ist es, was JWT, JWS, JWE, OAuth PKCE, WebPush VAPID und WebAuthn verwenden. Die beiden Zeichen, die sich unterscheiden, sind genau jene, die zuvor innerhalb von URLs eine Prozentcodierung benötigten (%2B für + und %2F für /), und das fehlende Padding umgeht auch %3D.

Standard- und URL-sicheres Base64 sind nicht direkt austauschbar. Ein Decoder, der das eine Alphabet kennt, weist Eingaben im anderen zurück. Wenn Sie Daten zwischen einem OAuth-Flow und einem Werkzeug durchleiten, das PEM-artiges Base64 erwartet, transcodieren Sie an der Grenze. Siehe unseren Vergleich Base64 vs. Base64url für die genauen Regeln.

MIME-Base64 (RFC 2045)

Die ursprüngliche Variante für E-Mail-Anhänge. Dasselbe Alphabet wie Standard-Base64, aber mit einem harten Zeilenumbruch (\r\n), der alle 76 Zeichen eingefügt wird, weil alte SMTP-Relays an langen Zeilen verschluckten. Leerraum innerhalb von MIME-Base64 muss vom Decoder ignoriert werden. Die meisten modernen Decoder akzeptieren Leerraum in jeder Base64-Eingabe stillschweigend, aber ein strikter RFC-4648-Decoder darf ihn zurückweisen. Wenn Sie Base64 für ein JSON- Feld oder ein JWT erzeugen, fügen Sie niemals Zeilenumbrüche ein.

Wo Base64 in freier Wildbahn auftaucht

• JWT-Tokens — drei base64url- (ungepolsterte) Abschnitte, durch Punkte verbunden. Header. Payload. Signatur.
• HTTP-Basic-Auth — username:password, Standard-Base64- codiert, gesendet im Authorization- Header. (Warum „Basic“ ohne TLS kein Sicherheitsmechanismus ist.)
• Data-URIs — data:image/png;base64,iVBORw0KG… bettet das Binäre direkt in HTML oder CSS ein. Der image/png-Teil ist ein MIME-Typ – ohne ihn muss der Browser die Bytes erschnüffeln und verweigert das Rendern womöglich.
• PEM-Dateien — TLS-Zertifikate, SSH-Schlüssel, PGP-Nachrichten. Standard-Base64, eingefasst in -----BEGIN…----- / -----END…------Header.
• E-Mail-Anhänge — MIME-Base64 mit 76-Zeichen-Zeilenumbruch.
• WebSocket-Frames über HTTP/2 — manche Nutzlasten verwenden Base64, wenn binäre Frames nicht verfügbar sind.
• Konfigurationsdateien — Kubernetes-Secret-Ressourcen sind Standard-Base64- codierte Werte (was bekanntermaßen Leute glauben lässt, sie seien verschlüsselt).

Häufige Fallstricke

Zeichenketten codieren ohne UTF-8 anzugeben

Base64 weiß nichts von Zeichen – es codiert Bytes. Wenn Sie die Zeichenkette “café” Base64- codieren, hängt das Ergebnis vollständig davon ab, welche Byte-Codierung Sie gewählt haben (UTF-8 ergibt 5 Bytes und erzeugt Y2Fmw6k=; Latin-1 ergibt 4 Bytes und erzeugt Y2Fm6Q==). Decodieren unter einer anderen Annahme ergibt Müll. Die moderne Konvention ist UTF-8-Bytes für jede Texteingabe.

Standard und URL-sicher vermischen

Eine Zeichenkette mit - oder _ ist base64url; Standard-Base64-Decoder weisen sie zurück. Eine Zeichenkette mit + oder / ist Standard; URL- sichere Decoder weisen sie zurück. Wenn Sie beide Enden kontrollieren, wählen Sie eines und dokumentieren es. Wenn nicht, normalisieren Sie bei der Eingabe durch Zeichenklassen-Substitution vor dem Decodieren.

Padding-Diskrepanz

JWTs und ähnliche Formate lassen das Padding weg. Naive Decoder verlangen Padding und werfen InvalidBase64. Die Lösung besteht darin, =-Zeichen wieder anzuhängen, bis die Eingabelänge ein Vielfaches von 4 ist – meist eines oder zwei davon.

Base64 als Sicherheitsgrenze behandeln

Kubernetes-Secrets sind Base64, nicht verschlüsselt. Ein Passwort im Client-Code mit Base64 zu codieren, schützt es nicht. Base64 verbirgt nichts vor jemandem mit einem Decoder – und jeder Laptop hat einen.

Data-URI-Aufblähung

Ein 200 KB großes Bild mit Base64 inline einzubetten, lässt es auf 266 KB wachsen und blockiert den Haupt- Thread, während der Browser die URI parst. Für alles jenseits weniger KB liefern Sie die Datei von einer normalen URL aus und lassen den Browser sie cachen.

Den Encoder ausprobieren

Fügen Sie beliebigen Text ein oder laden Sie eine Datei in unserem Base64-Encoder / -Decoder hoch. Er unterstützt sowohl das Standard- als auch das URL-sichere Alphabet, zeigt das Padding-Verhalten explizit an und meldet die Eingabe-/ Ausgabe-Bytegrößen, sodass Sie die Aufblähung für Ihre konkrete Eingabe sehen können. Der Base64-Glossareintrag ist die Ein-Absatz-Version.

Fazit

Base64 ist eine Transport-Bequemlichkeit, kein Sicherheitsmerkmal. Es kostet Sie ein Drittel Ihrer Bytes und zahlt es Ihnen in Kompatibilität mit reinen Text-Kanälen zurück. Die Varianten zählen – Standard für PEM und HTTP-Basic, URL-sicher für JWTs und OAuth, MIME für E-Mail – und sie decodieren einander nicht ohne Transcodierung. Seien Sie stets explizit darüber, welche Variante Sie erzeugen und konsumieren, und codieren Sie Unicode-Zeichenketten stets zuerst in UTF-8-Bytes.