Kodieren oder dekodieren Sie beide Varianten lokal mit dem Multi-Format-Encoder.
Was Base64 tatsächlich ist
Base64 wandelt Binärdaten in ASCII um, mit 64 Zeichen: A–Z, a–z, 0–9 sowie + und /. Ein abschließendes = dient als Padding, damit die Ausgabelänge ein Vielfaches von 4 bleibt.
Es ist eine Kodierung, keine Verschlüsselung – jeder kann Base64 ohne Schlüssel dekodieren. Der Zweck ist, Binärdaten durch textbasierte Kanäle wie E-Mail, JSON oder URLs zu transportieren.
Je drei Eingabebytes werden zu vier Ausgabezeichen: 24 Bits teilen sich in vier Gruppen zu je 6 Bits, und jede Gruppe wählt eines der 64 Alphabet-Zeichen. Deshalb ist die Ausgabe rund ein Drittel länger als die Eingabe.
Im Browser akzeptieren btoa() und atob() nur Ein-Byte-Zeichen (Latin-1). Geben Sie Emojis oder anderen UTF-8-Text hinein, werfen sie einen Fehler oder liefern Unsinn – TextEncoder wandelt UTF-8 vorher in Bytes um.
Warum URLs Standard-Base64 brechen
Die Zeichen + und / sind nicht URL-freundlich. In Query-Strings wird + als Leerzeichen interpretiert, und / kann ein Pfadsegment beenden.
Auch das Padding = macht Probleme: Manche Parser entfernen es, und kompakte Formate wie JWTs lassen es ohnehin weg.
Percent-Encoding kann das reparieren, aber jede Ebene, die die URL dekodiert, muss dasselbe Escaping erwarten. Die zwei Alphabet-Zeichen zu ersetzen beseitigt das Problem an der Quelle.
- + wird in Query-Strings als Leerzeichen gelesen
- / beendet oder spaltet ein Pfadsegment
- = Padding wird von manchen Parsern und Token-Formaten entfernt
Base64 vs. Base64URL im Überblick
Nur zwei Zeichen unterscheiden sich, und die dekodierten Bytes sind identisch. Ersetzen Sie + durch - und / durch _ und entfernen Sie das =-Padding – schon haben Sie die Base64URL-Form derselben Daten.
Die Padding-Zeile lohnt einen zweiten Blick: Standard-Base64 ist mit Padding definiert, Base64URL lässt es optional, und kompakte Formate wie JWT lassen es weg.
| Eigenschaft | Base64 | Base64URL |
|---|---|---|
| 62. Zeichen | + | - |
| 63. Zeichen | / | _ |
| Padding | Erforderlich | Meist entfernt |
| Typische Nutzung | E-Mail-MIME, Data-URIs | JWT, Dateinamen, Query-Strings |
| Decoder-Kompatibilität | Am weitesten verbreitet | Erfordert URL-sichere Behandlung |
Wann welche Variante
In der Praxis sind JWT-Segmente das Base64URL, das Sie am häufigsten sehen: Header, Payload und Signatur kommen ohne Padding an. Als ich ein JWT-Payload in einem CI-Skript dekodieren musste, half ein Wechsel auf den URL-sicheren Dekoder.
- Base64URL für JWT-Header und -Payload, Dateinamen und alles, was in URLs eingebettet wird
- Standard-Base64 für MIME-E-Mail-Anhänge und Daten, die nie URLs berühren
- Im Zweifel in Web-Apps Base64URL, in Legacy-Formaten Standard-Base64
Hinweis: Die Varianten unterscheiden sich nur im Alphabet und Padding. Ein JWT-Segment ist Base64URL ohne Padding; fügen Sie beim Dekodieren kein Padding hinzu.
Lokal kodieren und dekodieren
Das Werkzeug zeigt gepaddete und ungepaddete Ausgabe, und der Dekoder akzeptiert beides, sodass Sie ein JWT-Segment direkt in den Multi-Format-Encoder einfügen können.
- Öffnen Sie den Multi-Format-Encoder in Ihrem Browser.
- Wählen Sie Base64 oder Base64URL aus den Kodierungsoptionen.
- Fügen Sie Text oder eine Datei ein und kodieren Sie.
- Wechseln Sie zum Dekoder und prüfen Sie den Round-Trip.
FAQ
Q.Ist Base64URL immer noch Base64?
A.Ja. Dieselbe Idee und dieselben Padding-Regeln; nur zwei Alphabet-Zeichen ändern sich (- und _ statt + und /). Die dekodierten Bytes sind identisch, und die meisten Standardbibliotheken bieten eine URL-sichere Variante, etwa Buffer in Node, das base64-Modul in Python oder das base64-Paket in Go.
Q.Braucht Base64URL Padding?
A.Padding ist bei Base64URL optional und wird in kompakten Formaten wie JWT meist entfernt. Dekoder akzeptieren beide Formen, denn die Länge ist aus den Daten ableitbar (ein Vielfaches von 4). Von Hand ergänzen müssen Sie es selten, denn ein Dekoder fügt es wieder hinzu. atob() im Browser erwartet gepaddetes Standard-Base64; wandeln Sie Base64URL vorher um.
Q.Ist Base64URL sicherer als Base64?
A.Nein. Beides sind Kodierungen ohne Geheimnis; die Alphabet-Wahl ändert nichts an der Vertraulichkeit. Base64URL vermeidet nur URL-Parsing-Probleme. Bei Vertraulichkeit nutzen Sie echte Verschlüsselung wie AES-256-GCM und kodieren den Chiffretext mit Base64URL, falls er in einer URL reisen muss. Behandeln Sie Base64URL als Transportformat.
Referenzen
- RFC 4648 – The Base16, Base32, and Base64 Data Encodings: https://www.rfc-editor.org/rfc/rfc4648
- RFC 7515 – JSON Web Signature (JWS): https://www.rfc-editor.org/rfc/rfc7515
- MDN – btoa(): https://developer.mozilla.org/de/docs/Web/API/Window/btoa
Selbst kodieren
Base64, Base64URL, URL und Hex im Browser. Einfügen, kodieren, kopieren.
Base64URL für URLs, Base64 für MIME
Nutzen Sie Base64URL, wo Daten eine URL, einen Dateinamen oder ein JWT berühren. Behalten Sie Standard-Base64 für MIME-E-Mail und Formate, die nie eine URL sehen.
Keine Variante verbirgt etwas; verschlüsseln Sie Vertrauliches separat mit dem AES-256-GCM-Verschlüsselungs-Tool und kodieren Sie danach mit dem Multi-Format-Encoder.
Eine Gewohnheit, die Zeit spart: + oder / bedeutet Standard-Base64, - oder _ bedeutet Base64URL. Ein Blick genügt, um den richtigen Dekoder zu wählen.