JWT Decoder
Füge ein JSON Web Token ein, um Header und Payload zu lesen, zu sehen, wann es abläuft, und jeden Claim zu verstehen. Dein Token verlässt nie deinen Browser.
Läuft im BrowserOhne AnmeldungKein Upload
Dekodieren ist nicht Verifizieren. Header und Payload eines JWT kann jeder lesen, denn sie sind nur base64url-kodiert. Dieses Tool zeigt, was das Token behauptet; es beweist nicht, dass das Token echt ist. Verifiziere die Signatur immer auf deinem Server.
Header
Payload
Claims erklärt
Signatur verifizieren (optional, HS256/HS384/HS512)
Prüft eine HMAC-Signatur mit einem von dir eingegebenen Secret über die Web Crypto API deines Browsers. Das Secret verlässt diese Seite nie. RSA-/ECDSA-Tokens benötigen den Public Key des Ausstellers und werden hier nicht verifiziert.
Anleitung: JWT Decoder
- Füge das Token in das Feld Kodiertes Token ein. Ein vorangestelltes
Beareraus einem Authorization-Header wird ignoriert. - Header und Payload werden sofort dekodiert und als formatiertes JSON angezeigt.
- Lies die Tabelle Claims erklärt:
exp,iatundnbfwerden in Datumsangaben mit „läuft ab in“ / „abgelaufen vor“ umgerechnet. - Prüfe die Statusleiste auf Ablaufprobleme und die Warnungen auf riskante Einstellungen wie
alg: none. - Gib optional das Shared Secret ein, um eine HS256-, HS384- oder HS512-Signatur lokal zu verifizieren.
Was steckt in einem JWT?
Ein JSON Web Token (RFC 7519) besteht aus drei base64url-Strings, die durch Punkte verbunden sind: header.payload.signature. Der Header nennt den Signaturalgorithmus (alg) und den Token-Typ. Die Payload enthält die Claims, etwa wer der Nutzer ist und wann das Token abläuft. Die Signatur wird über die ersten beiden Teile mit einem Secret oder einem Private Key berechnet.
Dekodieren ist nicht Verifizieren
Header und Payload sind nur kodiert, nicht verschlüsselt; jeder, der das Token besitzt, kann sie lesen. Deshalb gehören Passwörter oder Secrets niemals in eine JWT-Payload. Dekodieren zeigt dir, was ein Token aussagt. Erst die Verifizierung der Signatur, normalerweise auf deinem API-Server mit einer Bibliothek wie jose oder PyJWT, beweist, wer es ausgestellt hat und dass es nicht verändert wurde. Ein Server muss außerdem exp, nbf, iss und aud prüfen und unerwartete Algorithmen ablehnen.
Spickzettel für registrierte Claims
| Claim | Bedeutung |
|---|---|
iss | Issuer: wer das Token erstellt und signiert hat |
sub | Subject: meist die Nutzer-ID |
aud | Audience: für welche API das Token bestimmt ist |
exp | Ablaufzeit in Sekunden seit der Unix-Epoche |
nbf | Nicht gültig vor diesem Zeitpunkt |
iat | Ausstellungszeitpunkt |
jti | Eindeutige Token-ID, nützlich für Sperrlisten |
„Token expired“-Fehler debuggen
Lehnt eine API ein scheinbar frisches Token ab, vergleiche exp und nbf mit der Serveruhr. Kleine Abweichungen der Uhren zwischen Rechnern sind üblich, daher erlauben die meisten Bibliotheken 30–60 Sekunden Toleranz. Prüfe außerdem, ob exp in Sekunden angegeben ist: Ein Wert in Millisekunden ist ein häufiger Bug und verlegt den Ablauf Tausende Jahre in die Zukunft.
Häufig gestellte Fragen
Ist es sicher, ein Produktions-JWT hier einzufügen?
Verifiziert dieses Tool die JWT-Signatur?
Warum wird mein Token als abgelaufen angezeigt?
exp-Claim liegt gemessen an der Uhr deines Computers in der Vergangenheit. Fordere ein neues Token an oder erneuere es mit deinem Refresh-Token. Wirken die Zeiten falsch, prüfe auf Uhrenabweichungen oder einen exp-Wert in Millisekunden.Was ist der Unterschied zwischen JWT, JWS und JWE?
Warum ist alg „none“ gefährlich?
alg: none ablehnen und sollten nur den konkreten Algorithmus akzeptieren, den sie erwarten.