Base64URL vs Base64: Was ist der Unterschied?

Der Unterschied zwischen base64url und base64 besteht aus drei kleinen Änderungen: Standard-base64 verwendet + und / in seinem Alphabet plus =-Padding, während base64url + durch - ersetzt, / durch _ ersetzt und das =-Padding meist ganz weglässt. Das ist der gesamte Unterschied auf Spezifikationsebene. Alles andere, die Kodierungsmathematik, die 6-Bit-Gruppierung, der 33%ige Größenaufschlag, ist zwischen beiden identisch.

Warum ist das wichtig? Weil +, / und = reservierte Bedeutungen in URLs, Query-Strings und Dateinamen haben. Wenn Sie einen standard-base64-String in eine URL einfügen, kann + als Leerzeichen interpretiert werden, / startet ein neues Pfadsegment und = sieht aus wie eine Parameterzuweisung. Base64url existiert, damit kodierte Daten diese Kontexte unverändert überstehen. Dieser Leitfaden behandelt genau, wann welche Variante erforderlich ist, die meist übersehene Falle des erneuten Paddings und warum JSON Web Tokens base64url für ihren Header und Payload verwenden.

Base64url vs Base64: Der wesentliche Unterschied#

Beide Varianten sind in RFC 4648 definiert. Standard-Base64 befindet sich in Abschnitt 4; das URL- und dateinamensichere Alphabet in Abschnitt 5. Sie kodieren Bytes auf die gleiche Weise: Drei Bytes (24 Bits) werden in vier 6-Bit-Gruppen aufgeteilt, und jede Gruppe wird einem Zeichen aus einem 64-Zeichen-Alphabet zugeordnet. Der einzige Unterschied besteht darin, welche Zeichen die letzten beiden Positionen dieses Alphabets füllen und ob am Ende aufgefüllt wird.

Hier ist der direkte Vergleich, der wirklich zählt:

Aspekt	Standard-Base64	Base64url
Zeichen für Index 62	+ (Plus)	- (Bindestrich)
Zeichen für Index 63	/ (Schrägstrich)	_ (Unterstrich)
Auffüllung	= auf ein Vielfaches von 4	Meist weggelassen
Sicher in URLs / Query-Strings	Nein	Ja
Sicher in Dateinamen	Nein (/ unterbricht Pfade)	Ja
RFC 4648 Abschnitt	Abschnitt 4	Abschnitt 5
Ausgabelänge	Identisch	Identisch

Beachten Sie, dass die ersten 62 Zeichen (A-Z, a-z, 0-9) in beiden Alphabeten gleich sind. Nur die Positionen 62 und 63 unterscheiden sich. Deshalb ist die Konvertierung zwischen beiden eine triviale Zeichensubstitution und erfordert nie eine Neukodierung der ursprünglichen Bytes.

Kurzer Tipp: Wenn Sie jemals einen base64-ähnlichen String mit - oder _ sehen, handelt es sich mit hoher Wahrscheinlichkeit um Base64url. Reines Base64 verwendet diese beiden Zeichen nie.

Warum + und / in URLs stören#

Eine URL hat eine Grammatik, und mehrere Zeichen tragen strukturelle Bedeutung. Der Schrägstrich / trennt Pfadsegmente. Das Pluszeichen + wird historisch als kodiertes Leerzeichen in application/x-www-form-urlencoded-Daten interpretiert (das Format, das von Query-Strings und Formularübermittlungen verwendet wird). Das Gleichheitszeichen = trennt einen Query-Parameternamen von seinem Wert.

Wenn Sie also ein Standard-Base64-Token wie a+b/c= direkt in eine URL setzen, könnte ein Server das + als Leerzeichen dekodieren, /c als neuen Pfad behandeln und = als Beginn eines Wertes interpretieren. Ihre Daten sind dann beschädigt, bevor Ihr Code sie überhaupt berührt. Base64url umgeht das gesamte Problem, indem es nie eines dieser drei Zeichen ausgibt.

Wann Sie jede Variante verwenden müssen#

Die Entscheidungsregel ist kurz. Verwenden Sie base64url überall dort, wo die Ausgabe durch eine URL, einen Query-Parameter, einen HTTP-Header, einen Dateinamen oder ein Cookie wandert. Verwenden Sie Standard-Base64 für alles andere: E-Mail-Anhänge (MIME), Data-URIs, Konfigurationsdateien, JSON-String-Werte, die nicht URL-gebunden sind, und binäre Blobs, die in einer Datenbank gespeichert werden.

Verwenden Sie base64url, wenn der codierte Wert in folgenden Kontexten erscheint:

• Einem URL-Pfad oder Query-String (zum Beispiel ?token=...)
• Einem JWT (Header, Payload und Signatur sind alle base64url)
• Einem OAuth- oder OpenID-Connect-Parameter wie state oder code_challenge
• Einem Dateinamen oder S3-Objekt-Schlüssel (das / in Standard-Base64 würde unbeabsichtigte Ordner erzeugen)
• WebPush-Schlüsseln, FIDO/WebAuthn-Anmeldedaten und vielen anderen Web-Crypto-Kontexten

Verwenden Sie Standard-Base64, wenn der Wert in folgenden Kontexten lebt:

• Einem als MIME codierten E-Mail-Anhang
• Einer data:-URI, die in HTML oder CSS eingebettet ist (diese tolerieren + und / problemlos)
• Einem JSON- oder YAML-Konfigurationswert, der niemals in einer URL platziert wird
• Einer Datenbankspalte oder Logzeile

Wenn Sie nicht sicher sind, welche Variante Sie haben, fügen Sie sie in den kostenlosen Base64-Kodierer und -Dekodierer ein und dekodieren Sie sie auf beide Arten. Wenn nur eine Variante saubere, lesbare Ausgabe liefert, wissen Sie, welches Alphabet sie erzeugt hat.

Die Padding-Falle, die die meisten Anleitungen verschweigen#

Das ist der Teil, der viele verwirrt und der Grund, warum ein kopierter Snippet manchmal einen Fehler wirft. Standard-Base64 füllt die Ausgabe mit = auf, sodass die Gesamtlänge immer ein Vielfaches von 4 ist. Base64url entfernt dieses Padding normalerweise, da = selbst unsicher in URLs ist.

Die Mathematik: Base64 kodiert 3 Bytes in 4 Zeichen. Wenn Ihre Eingabe kein Vielfaches von 3 Bytes ist, füllt der Kodierer die Lücke mit =. Ein übrig gebliebenes Byte erzeugt zwei Padding-Zeichen (==), zwei übrig gebliebene Bytes erzeugen eines (=).

Hier ist die Falle. Viele strenge Dekodierer verlangen eine Länge, die ein Vielfaches von 4 ist. Wenn Base64url das Padding entfernt, ist die Zeichenfolgenlänge kein Vielfaches von 4 mehr, sodass ein naiver Dekodierer fehlschlägt. Die Lösung ist, vor dem Dekodieren wieder aufzufüllen.

Wie man Base64url vor dem Dekodieren wieder auffüllt#

Um eine Base64url-Zeichenfolge sicher mit einem generischen Base64-Dekodierer zu dekodieren, müssen Sie zwei Dinge tun: Das Alphabet zurückkonvertieren (- zu +, _ zu /) und dann = hinzufügen, bis die Länge ein Vielfaches von 4 ist.

In JavaScript:

function base64urlDecode(input) {
  // 1. Stelle das Standardalphabet wieder her
  let b64 = input.replace(/-/g, '+').replace(/_/g, '/');
  // 2. Fülle auf ein Vielfaches von 4 auf
  const pad = b64.length % 4;
  if (pad === 2) b64 += '==';
  else if (pad === 3) b64 += '=';
  else if (pad === 1) throw new Error('Ungültige Base64url-Länge');
  return atob(b64);
}

Ein Rest von 1 bei der Länge ist bei gültigem Base64 unmöglich, behandeln Sie es also als fehlerhafte Eingabe, anstatt zu raten. Wenn Sie den Schritt des Wiederauffüllens überspringen, werden atob und die meisten serverseitigen Dekodierer die Zeichenfolge ablehnen oder Müll zurückgeben. Unser Base64-Codec handhabt das Wiederauffüllen automatisch, sodass Sie ein ungefülltes Base64url-Token einfügen können und es dekodiert wird, ohne dass Sie die Arithmetik selbst durchführen müssen.

Warum JWTs Base64url (nicht Base64) verwenden#

Ein JSON Web Token besteht aus drei Base64url-Segmenten, die durch Punkte getrennt sind: header.payload.signature. Der Grund, warum Base64url und nicht das Standard-Base64 verwendet wird, liegt genau in dem oben genannten Problem. Tokens werden in URLs, in Authorization: Bearer-Headern und in OAuth-Flows als Query-Parameter übergeben. Ein Standard-Base64-Token mit einem / oder + würde beim Auftreffen auf eine URL sofort brechen.

Daher schreibt der JWT-Standard (RFC 7519, aufbauend auf RFC 7515) Base64url ohne Padding vor. Deshalb enthält ein JWT niemals =, + oder /, sondern nur Buchstaben, Ziffern, Bindestriche, Unterstriche und die beiden Punkt-Trennzeichen.

Warnung: Base64url ist eine Kodierung, keine Verschlüsselung. Jeder kann die Nutzlast eines JWT dekodieren und seine Claims lesen. Setzen Sie niemals Geheimnisse in einen JWT-Body. Die Signatur beweist, dass das Token nicht manipuliert wurde, verbirgt jedoch nicht den Inhalt.

Wenn Sie ein Token inspizieren möchten, können Sie die drei Segmente trennen und den Header sowie die Nutzlast mit dem JWT-Decoder-Tool Base64url-dekodieren. Es führt die Alphabet-Konvertierung und das erneute Padding für Sie durch, sodass Sie die rohen JSON-Claims sofort sehen. Um zu verstehen, was das Signatur-Segment im Vergleich zur reinen Dekodierung beweist, lohnt sich die Aufschlüsselung in Dekodieren vs. Verifizieren eines JWT, bevor Sie einem Token in der Produktion vertrauen.

Konvertierung zwischen den beiden Varianten#

Da sich nur zwei Zeichen und die Auffüllung unterscheiden, ist die Konvertierung reine Zeichenkettenmanipulation. Sie führen den base64-Algorithmus nie erneut aus.

Standard-base64 zu base64url:

• Ersetzen Sie jedes + durch -
• Ersetzen Sie jedes / durch _
• Entfernen Sie abschließende =-Zeichen

Base64url zurück zu Standard-base64:

• Ersetzen Sie jedes - durch +
• Ersetzen Sie jedes _ durch /
• Fügen Sie =-Auffüllung hinzu, bis die Länge ein Vielfaches von 4 ist

Diese Symmetrie ist die praktische Erkenntnis: Die beiden Formate sind dieselben Daten in unterschiedlicher Kleidung. Wenn eine Dekodierung fehlschlägt, liegt die Ursache fast immer an einer Nichtübereinstimmung (Sie haben base64url in einen Standard-Decoder eingegeben, ohne zu konvertieren) oder an fehlender Auffüllung, nicht an beschädigten Daten.

Ein durchgerechnetes Beispiel#

Nehmen Sie die Bytes für die Zeichenfolge Hello?>. Standard-base64 kodiert sie zu SGVsbG8/Pg==. Beachten Sie das / an Index 8 und die ==-Auffüllung. Als base64url werden dieselben Bytes zu SGVsbG8_Pg: das / ist jetzt _ und die Auffüllung ist weg. Dekodieren Sie eine der beiden und Sie erhalten Hello?> zurück. Gleicher Inhalt, zwei für verschiedene Kontexte sichere Darstellungen.

Häufige Fehler und wie man sie vermeidet#

Einige Fehler treten bei Entwicklern immer wieder auf, wenn sie die beiden Varianten mischen:

• Decodieren von base64url mit einem Standard-Decoder und Erhalten einer Fehlermeldung. Konvertieren Sie zuerst -/_ zurück und fügen Sie Padding hinzu. Dies ist der mit Abstand häufigste Fehler.
• Annehmen, dass = immer vorhanden ist. Code, der auf Padding-Länge prüft oder diese aufteilt, bricht, sobald er auf ungepadetes base64url trifft. Machen Sie Padding in Ihrer Analyse optional.
• URL-Codieren eines Standard-base64-Strings anstelle von base64url. Dies funktioniert, bläht die Ausgabe jedoch auf: + wird zu %2B, / wird zu %2F. Base64url ist kürzer und sauberer für URL-Kontexte.
• Behandeln von base64 oder base64url als Sicherheitsschicht. Beide sind für jeden umkehrbar. Verwenden Sie sie, um Binärdaten als Text zu transportieren, niemals zum Schutz von Daten.
• Vergessen, dass beide Formate den gleichen 33%igen Größen-Overhead haben. Das Codieren von 3 Bytes als 4 Zeichen bedeutet, dass Ihre Ausgabe in beiden Varianten etwa ein Drittel größer ist als die Rohdaten.

Wenn Sie codierte Binärdaten wie Bilder zusammen mit Text verarbeiten, deckt der Leitfaden zum Codieren und Decodieren von base64-Bildern und Data-URLs die Data-URI-Seite ab, bei der Standard-base64 die richtige Wahl ist.

Häufig gestellte Fragen#

Ist base64url dasselbe wie base64? Nein, aber sie sind sich ähnlich. Base64url verwendet denselben Kodierungsalgorithmus und erzeugt dieselbe Ausgabelänge. Die einzigen Unterschiede sind, dass + zu - wird, / zu _ und die =-Auffüllung normalerweise weggelassen wird, damit die Zeichenfolge sicher in URLs und Dateinamen verwendet werden kann.

Warum entfernt base64url die Auffüllung? Das Auffüllzeichen = hat in URLs eine reservierte Bedeutung (es trennt einen Abfrageparameternamen von seinem Wert). Wenn es erhalten bliebe, könnte es die Daten beschädigen oder einen Server verwirren. Base64url lässt es aus Sicherheitsgründen weg. Der Nachteil ist, dass strenge Dekodierer möglicherweise verlangen, dass Sie die Auffüllung vor dem Dekodieren wieder hinzufügen.

Kann ich base64url mit einem normalen base64-Dekodierer dekodieren? Ja, aber nur nach zwei Schritten. Konvertieren Sie zuerst das Alphabet zurück, indem Sie - durch + und _ durch / ersetzen. Fügen Sie dann die Zeichenfolge mit = wieder auf, bis ihre Länge ein Vielfaches von 4 ist. Überspringen Sie einen Schritt, und die meisten Standard-Dekodierer geben einen Fehler oder Müll aus.

Warum verwenden JWTs base64url anstelle von standardmäßigem base64? Weil Token durch URLs, HTTP-Header und OAuth-Parameter reisen, wo +, / und = stören würden. Die JWT-Spezifikation schreibt base64url ohne Auffüllung vor. Deshalb sehen Sie in einem gültigen JSON Web Token nie diese drei Zeichen, sondern nur Buchstaben, Ziffern, Bindestriche, Unterstriche und Punkt-Trennzeichen.

Ist base64url Verschlüsselung oder nur Kodierung? Es ist nur Kodierung. Jeder kann es ohne Schlüssel rückgängig machen, genau wie bei standardmäßigem base64. Es dient dazu, Binärdaten als URL-sicheren Text darzustellen, nicht um etwas geheim zu halten. Speichern Sie niemals Passwörter, API-Schlüssel oder andere sensible Daten als base64url und gehen Sie davon aus, dass sie geschützt sind.

Erzeugt base64url eine kleinere Zeichenfolge als base64? Leicht, nur weil es normalerweise die =-Auffüllung weglässt (Einsparung von null bis zwei Zeichen). Der kodierte Hauptteil hat in beiden Fällen dieselbe Länge. Beide Varianten fügen denselben ungefähren Overhead von 33 % gegenüber den rohen Binärdaten hinzu, da alle 3 Bytes zu 4 Zeichen werden.

Base64url vs. base64 ist kein großes Geheimnis, wenn man es als ein Alphabet mit zwei ausgetauschten Zeichen und optionaler Auffüllung betrachtet. Greifen Sie zu base64url, wenn Ihre Daten eine URL, einen Header, einen Dateinamen oder ein JWT berühren, und zu standardmäßigem base64 für MIME, Daten-URIs und Speicherung. Wenn eine Dekodierung fehlschlägt, vermuten Sie zuerst eine Variantenabweichung oder fehlende Auffüllung und geben Sie die Zeichenfolge dann in den base64-Kodierer und -Dekodierer ein, um zu bestätigen, welches Alphabet Sie haben.