Zum Hauptinhalt springen
ToolsByUs

JWT dekodieren

Dieses Tool liest Header und Payload eines JSON Web Token in Ihrem Browser und erklärt, was er findet: den Signaturalgorithmus, jeden Claim mit seiner Bedeutung und die Ablaufzeit, dekodiert in ein echtes Datum. Er verifiziert nie die Signatur, denn das würde bedeuten, Ihr Token an denjenigen zu senden, der den Schlüssel hält.

Nur lokal
JSON Web Token
0 B1 ZeileZ. 1, Sp. 1
Nichts zu decodieren. Fügen Sie oben ein Token ein. Es wird nichts hochgeladen; die Decodierung erfolgt in diesem Tab.

Wie funktioniert JWT dekodieren?

Ein JSON Web Token besteht aus drei base64url-kodierten Segmenten, getrennt durch Punkte: header.payload.signature. Die ersten beiden sind JSON-Objekte, und sie sind nicht verschlüsselt – base64url ist eine Kodierung, keine Chiffre. Jeder, der das Token hat, kann jeden Claim darin lesen; deshalb ist es ein Fehler, den Leute regelmäßig machen und spät entdecken, ein Passwort, eine Kartennummer oder eine interne Datenbank-ID in eine JWT-Payload zu schreiben.

Dekodieren ist daher unkompliziert: an den Punkten trennen, die ersten beiden Segmente base64url-dekodieren, jedes davon als JSON parsen. Die Sorgfalt steckt in den Details, an denen naive Dekoder scheitern. JWT-Segmente sind base64url ohne Padding (RFC 7515 §2); ein Dekoder, der ein = -Padding verlangt, verwirft die meisten echten Tokens. Das Alphabet nutzt - und _ statt + und /, daher scheitert ein Standard-Base64-Dekoder an rund der Hälfte aller Tokens, je nachdem, was die Zufallsbytes gerade ergeben.

Was dieses Tool über das Dekodieren hinaus beiträgt, ist die Interpretation. Registrierte Claims aus RFC 7519 werden mit ihrer Bedeutung annotiert. exp, nbf und iat sind NumericDates – Sekunden seit der Unix-Epoche – und werden deshalb als echter Zeitstempel und relative Zeit dargestellt, denn mit „1757546000“ kann man nichts anfangen, mit „vor 4 Stunden abgelaufen“ schon.

Dann sucht es nach den konkreten Problemen, die Vorfälle auslösen: einem alg von none, einem leeren Signatursegment, einem Token ohne exp, einem Token, das noch nicht gültig ist, weil die Uhr des Issuers vorgeht, und einem fehlenden aud, das es erlaubt, das Token gegen einen anderen Dienst zu wiederholen, der demselben Issuer vertraut.

Bewusst hört es vor der Verifikation auf. Eine Signatur zu prüfen erfordert das Secret oder den öffentlichen Schlüssel des Issuers, und die einzige Möglichkeit, wie eine Webseite an eines kommt, ist, Ihr Token irgendwohin zu senden. Das anzubieten würde die eine Eigenschaft zunichtemachen, die es sicher macht, ein aktives Credential in diese Seite einzufügen.

Token-Segment

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  .eyJzdWIiOiJ1c3JfOGYyYTFiIiwiZXhwIjoxNzU3NTQ2MDAwfQ
  .3Zc0Kz1qHhVQ9oFmR2sT7xYbN4dJwEuLpAiCgXvKmO8

Dekodiert

header  { "alg": "HS256", "typ": "JWT" }
payload { "sub": "usr_8f2a1b", "exp": 1757546000 }

exp  2026-09-10 21:53:20 UTC  (expired)
sub  Subject — who the token is about

Welche Optionen und Sonderfälle unterstützt JWT dekodieren?

Technische Referenz und Optionen
ParameterTypStandardVerhalten & Sonderfälle
algstringerforderlichSignaturalgorithmus, im Header. HS* ist HMAC mit einem gemeinsamen Secret; RS*/PS* sind RSA; ES* ist ECDSA; EdDSA ist Ed25519. Ein Wert von "none" wird als Fehler markiert: Eine Bibliothek, die alg aus dem Token selbst vertraut, lässt jeden ein Token fälschen.
typ / kidstringoptionaltyp ist konventionell "JWT". kid identifiziert, welcher Schlüssel das Token signiert, und ermöglicht es einem Aussteller, Schlüssel zu rotieren, ohne dass alles auf einmal ungültig wird.
expNumericDateoptionalSekunden seit der Unix-Epoche, nicht Millisekunden und kein ISO-String. Hier dekodiert zu einem UTC-Zeitstempel und einer relativen Zeit. Ein Token ohne exp läuft nie von selbst ab und kann nur durch Widerruf gestoppt werden.
nbfNumericDateoptionalNot-before. Ein Token, das noch nicht gültig ist, ist fast immer eine Uhrenabweichung zwischen dem ausstellenden Server und der Maschine, die es liest, und nicht eine beabsichtigte Verzögerung.
audstring | string[]optionalBeabsichtigter Empfänger. Ein Dienst muss ein Token zurückweisen, dessen Empfänger nicht er selbst ist; ohne aud kann ein Token, das für einen Dienst erstellt wurde, bei einem anderen wiedergegeben werden, der denselben Aussteller vertraut.
Segment-Encodingbase64urlohne PaddingRFC 7515 §2 verwendet das URL-sichere Alphabet (- und _) ohne Padding. Standard-Base64-Decoder schlagen bei Tokens fehl, deren Bytes + oder / erzeugen, was der Grund ist, warum ein Token manchmal in einem Tool dekodiert wird und in einem anderen nicht.
Signaturbase64urlnicht überprüftWird angezeigt, aber nie überprüft. Die Überprüfung erfordert den Schlüssel des Ausstellers; einen zu beschaffen, würde bedeuten, Ihr Token zu übermitteln. Ein leeres Signatursegment wird markiert, da es bedeutet, dass überhaupt keine Integritätsschutz vorhanden ist.
Eingabegrößebytes8 MBDas Main-Thread-Limit, das auf der gesamten Website gemeinsam genutzt wird. Echte Tokens sind wenige Kilobytes; das Limit besteht darin, dass das Einfügen des falschen Inhalts den Tab nicht einfrieren kann.

Häufig gestellte Fragen

Kann ich ein echtes JWT gefahrlos in diese Seite einfügen?

Das Dekodieren geschieht vollständig in Ihrem Browser, und das Token wird nie übertragen – öffnen Sie die DevTools, wechseln Sie in den Netzwerk-Tab, fügen Sie ein Token ein, und Sie werden keinen Request sehen, der es trägt. Das macht diese Seite prinzipiell sicherer als einen Dekoder, der an einen Server postet und Ihr Token in einem Access-Log landen lässt. Der verbleibende Vorbehalt betrifft nicht diese Seite: Jedes Credential, das Sie in irgendeinen Browser auf einem Gerät einfügen, das Sie nicht kontrollieren, sollten Sie danach rotieren.

Warum kann es die Signatur nicht verifizieren?

Weil die Verifikation den Schlüssel braucht. Bei HS256 ist es das gemeinsame Secret; bei RS256 ist es der öffentliche Schlüssel des Issuers, meist bezogen über einen JWKS-Endpunkt. Eine Browserseite könnte beides nur, indem sie Ihr Token oder das Secret irgendwohin sendet – was die Eigenschaft zerstören würde, die diese Seite sicher zu benutzen macht. Die Verifikation gehört in Ihren Dienst, wo der Schlüssel ohnehin liegt.

Mein Token dekodiert hier, aber meine Bibliothek weist es zurück. Warum?

Dekodieren und Akzeptieren sind verschiedene Fragen. Die häufigsten Ursachen: Das Token ist abgelaufen (prüfen Sie die exp-Zeile – dieses Tool zeigt sie als echtes Datum); die Audience stimmt nicht mit dem überein, was Ihr Dienst erwartet; das nbf liegt in der Zukunft, weil die Uhr des ausstellenden Servers vorgeht; oder die Signatur verifiziert nicht gegen den Schlüssel, mit dem Ihr Dienst konfiguriert ist – oft, weil der Issuer die Schlüssel rotiert hat und das kid auf einen verweist, den Ihr Cache noch nicht übernommen hat.

Was bedeutet alg: none und warum wird es als Fehler markiert?

Es bedeutet, dass das Token nicht signiert ist. Die Gefahr liegt nicht im Wert selbst, sondern darin, was ein Verifizierer damit macht: Manche JWT-Bibliotheken lasen historisch den alg aus dem Token und wählten entsprechend die Verifikationsmethode; ein Angreifer konnte also ein gültiges Token nehmen, den Algorithmus auf none ändern, die Signatur streichen – und das Token wurde akzeptiert. Ein korrekter Verifizierer legt den erwarteten Algorithmus über seine eigene Konfiguration fest und ignoriert, was das Token behauptet.

Ist ein JWT verschlüsselt?

Nein. Ein Standard-JWT (ein JWS) ist signiert, nicht verschlüsselt – die Signatur belegt, dass die Payload nicht verändert wurde, und verbirgt sie in nichts. Jeder Claim ist für jeden lesbar, der das Token hat; genau das demonstriert diese Seite. Wenn die Inhalte verborgen bleiben sollen, brauchen Sie ein JWE, das fünf statt drei Segmente hat und ohne den Entschlüsselungsschlüssel nicht lesbar ist.

Kann ich ein bereits abgelaufenes Token dekodieren?

Ja. Der Ablauf ist ein Claim in der Payload, keine Eigenschaft der Kodierung; ein abgelaufenes Token dekodiert sich also exakt wie ein gültiges. Dieses Tool liest ihn und sagt Ihnen, wann es abgelaufen ist und wie lange her – meist der schnellste Weg, um zu bestätigen, dass ein zeitweiser 401 ein Problem der Token-Lebensdauer ist und keines der Berechtigungen.

Was kann JWT dekodieren sonst noch?

ToolsByUs-Team · Wie wir unsere Tools prüfen