Base64 / URL / JWT Encoder & Decoder

Base64 oder URLs kodieren und dekodieren sowie Header und Payload eines JWT im Browser ansehen.

Text oder JWT

Ausgabe

So geht's

Geben Sie Ihre Eingabe in das Feld „Text oder JWT“ ein oder fügen Sie sie dort ein: Klartext zum Kodieren, eine Base64- oder prozentkodierte Zeichenkette zum Dekodieren oder ein JWT zum Untersuchen.
Klicken Sie auf „Base64 kodieren“ oder „Base64 dekodieren“, um zwischen Text und Base64 umzuwandeln, oder auf „URL kodieren“ bzw. „URL dekodieren“, um die Prozentkodierung hinzuzufügen oder zu entfernen. Das Ergebnis oder eine Fehlermeldung erscheint im Feld „Ausgabe“.
Um ein Token zu untersuchen, fügen Sie es mit oder ohne das Präfix Bearer ein und klicken Sie auf „JWT dekodieren“. Header und Payload erscheinen als eingerücktes JSON, und vorhandene Claims iat, nbf und exp in der Payload werden unter „Zeit-Claims des JWT“ aufgeführt, wobei numerische Werte in UTC und in Ihre Ortszeit umgerechnet werden.
Klicken Sie auf „Ergebnis kopieren“, um die Ausgabe zu kopieren. Um eine Kodierung rückgängig zu machen, fügen Sie den kodierten Text in das Feld „Text oder JWT“ ein und klicken Sie auf die passende Schaltfläche zum Dekodieren. Dekodieren und erneutes Kodieren ergibt nicht unbedingt wieder genau das Original: URL-sicheres Base64 oder Base64 ohne Padding kommt im Standardalphabet und, wo nötig, mit =-Padding zurück, und „URL kodieren“ macht aus einem +, das „URL dekodieren“ stehen gelassen hat, %2B.

Häufig gestellte Fragen

Werden der eingefügte Text oder das Token irgendwohin gesendet?

Nein. Kodieren und Dekodieren laufen per JavaScript in Ihrem Browser, und Ihre Eingaben werden nicht an LeedyBox gesendet. Ein JWT dient jedoch oft als Anmeldenachweis und kann für jeden funktionieren, der es besitzt, bis es abläuft oder widerrufen wird. Behandeln Sie ein gültiges Token daher wie ein Passwort und teilen Sie es nicht in Screenshots oder Chats.

Warum meldet „Base64 dekodieren“, dass die Daten kein gültiger UTF-8-Text sind?

„Base64 dekodieren“ zeigt die dekodierten Bytes als UTF-8-Text an und bricht mit diesem Fehler ab, wenn sie kein gültiges UTF-8 sind, etwa bei PNG- oder JPEG-Bildern, den meisten PDFs und komprimierten Daten und oft auch bei Text in einer anderen Kodierung wie Latin-1 oder Shift_JIS. Das Tool speichert dekodierte Bytes nicht als Datei; verwenden Sie es also für Base64, das Text enthält. Ein Data-URI wie data:image/png;base64,... wird als ungültiges Base64 abgelehnt, weil Doppelpunkt, Semikolon und Komma keine Base64-Zeichen sind.

Werden URL-sicheres Base64 und fehlendes Padding unterstützt?

Beim Dekodieren ja: „Base64 dekodieren“ akzeptiert das Standardalphabet (+ und /) und das URL-sichere Alphabet (- und _), mit oder ohne =-Padding, und ignoriert Leerzeichen und Zeilenumbrüche. „Base64 kodieren“ gibt das Standardalphabet mit Padding aus; für die URL-sichere Form, wie sie in JWTs verwendet wird, ersetzen Sie + durch -, / durch _ und entfernen die =-Zeichen am Ende. Der Text wird genau wie eingegeben als UTF-8 kodiert, daher ändert ein Leerzeichen oder Zeilenumbruch am Ende das Ergebnis, und Zeilenumbrüche im Feld werden als LF kodiert.

Sollte ich eine ganze URL mit „URL kodieren“ kodieren?

In der Regel nicht. „URL kodieren“ arbeitet wie encodeURIComponent in JavaScript: Es prozentkodiert alle Zeichen außer A–Z, a–z, 0–9 und - _ . ! ~ * ' ( ), daher werden auch die Zeichen / ? & = : und # kodiert, die eine URL gliedern. Verwenden Sie es für einen einzelnen Teil, etwa den Wert eines Query-Parameters. Leerzeichen werden zu %20, und Nicht-ASCII-Zeichen werden als ihre UTF-8-Bytes kodiert, sodass é zu %C3%A9 wird.

Warum werden Pluszeichen nicht in Leerzeichen umgewandelt, und wann meldet „URL dekodieren“ einen Fehler?

„URL dekodieren“ arbeitet wie decodeURIComponent in JavaScript: Es dekodiert %XX-Escape-Sequenzen und lässt + unverändert, weil + in der allgemeinen URL-Syntax (RFC 3986) nicht für ein Leerzeichen steht. HTML-Formulardaten (application/x-www-form-urlencoded), wie sie in vielen Query-Strings vorkommen, kodieren Leerzeichen dagegen als +; ersetzen Sie bei solchen Daten daher vor dem Dekodieren jedes + durch ein Leerzeichen. Ein echtes Pluszeichen wird in diesem Format als %2B geschrieben und trotzdem korrekt dekodiert. Der Fehler erscheint, wenn auf ein % keine zwei Hexadezimalziffern folgen, wie in 50% off, oder wenn die kodierten Bytes kein gültiges UTF-8 sind, wie in %E2%82.

Welche Tokens kann „JWT dekodieren“ lesen?

Tokens in der dreiteiligen kompakten Form header.payload.signature, wie sie signierte JWTs (JWS) verwenden, einschließlich unsignierter Tokens mit leerem Signaturteil. Der Signaturteil wird nicht geprüft, ein dekodiertes Token ist also kein Beweis für seine Echtheit. Verschlüsselte Tokens (JWE) bestehen aus fünf Teilen, und ihre Payload ist ohne Schlüssel nicht lesbar, daher erhalten sie einen Formatfehler. Ein Header oder eine Payload, die sich nicht von Base64 zu JSON dekodieren lässt, oder eine Payload, die statt eines JSON-Objekts ein einfacher Wert wie eine Zeichenkette oder Zahl ist, führt zur Meldung „Fehler beim Lesen des JWT“. Ganzzahlen über 9.007.199.254.740.991 in Header oder Payload können beim Einlesen des JSON im Browser gerundet werden, sodass lange numerische IDs mit abweichenden letzten Ziffern angezeigt werden können.

Wie werden die Zeiten exp, nbf und iat angezeigt, und wann gilt ein Token als abgelaufen?

Die Werte werden, wie im JWT-Standard (RFC 7519) festgelegt, als Unix-Zeit in Sekunden gelesen und in UTC und in Ihrer Ortszeit angezeigt. „ABGELAUFEN“ und „Noch nicht gültig“ vergleichen exp und nbf mit der Uhr Ihres Geräts im Moment des Klicks auf „JWT dekodieren“, ohne Toleranz für Zeitabweichungen; geht die Uhr falsch, ist auch der Status falsch. Server lassen unter Umständen einen kleinen Spielraum zu, oft nicht mehr als einige Minuten, sodass ein Server in der Nähe des exp- oder nbf-Zeitpunkts anders entscheiden kann als der hier angezeigte Status. Eine als Zeichenkette geschriebene Zeit wie "1700000000" wird als ungültiger numerischer Unix-Zeitstempel gemeldet.