JWT Decoder
Füge ein JWT ein, um Header, Payload und Signatur zu sehen, herauszufinden, ob es noch gültig ist, und seine Rollen und Scopes zu prüfen. Dekodiert wird schon beim Einfügen.
Token, Secret und Public Key bleiben in deinem Browser. Nichts davon wird an einen Server gesendet, auch nicht an unseren, und alles ist weg, sobald du die Seite schließt.
Noch kein Token
Füge ein JWT in das Feld ein. Status, Zeitpunkte und Claims erscheinen hier sofort.
Brauchst du ein Token mit anderen Claims, etwa für einen Admin und einen normalen Nutzer?
Wie benutzt man den JWT Decoder?
Token einfügen
Kopiere es aus den DevTools, aus Postman oder einem Log und füge es ein. Bearer, Anführungszeichen und Zeilenumbrüche werden automatisch entfernt.
Status ansehen
Der Status zeigt, ob das Token abgelaufen ist, wann es abläuft und zu welcher Uhrzeit, in deiner Zeitzone und in UTC.
Signatur prüfen
Gib das Secret oder den Public Key ein, um zu erfahren, ob das Token echt und unverändert ist.
Kopieren, was du brauchst
Kopiere das bereinigte Token, den Header, den Payload oder den Wert eines Claims mit einem Klick.
Was ist ein JWT?
Ein JWT (JSON Web Token, RFC 7519) ist ein Token-Format, um Informationen zwischen Systemen weiterzugeben, vor allem beim Login und bei der Autorisierung von APIs. Der Authentifizierungsserver stellt das Token nach dem Login aus, die Anwendung schickt es bei jeder Anfrage mit, und die API liest die Claims, um zu wissen, wer der Nutzer ist und was er darf.
Die drei Teile eines JWT
Ein JWT besteht aus drei base64url-Abschnitten, getrennt durch Punkte:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGVzIjpbInVzZXIiXX0.3mG4X8mY2bJqS0mY7fUv0M1wS6Qy0p2WmH0x0J3bQKc- Header. Der Header nennt den Algorithmus, der das Token signiert hat (alg), und manchmal den verwendeten Schlüssel (kid).
- Payload. Der Payload enthält die Claims: wer der Nutzer ist, wann das Token abläuft, für welche API es gilt und welche Berechtigungen es gewährt.
- Signatur. Die Signatur wird über Header und Payload berechnet. Ändert sich ein einziges Zeichen, passt sie nicht mehr.
Warum man den Payload ohne Passwort lesen kann
Header und Payload sind nur base64url-kodiert, eine Base64-Variante, die + und / durch - und _ ersetzt und das = am Ende weglässt. Kodieren ist kein Verschlüsseln: Wer das Token hat, kann den Inhalt lesen, und genau das macht dieses Tool. Deshalb haben Passwörter, Kartennummern und andere sensible Daten im Payload eines JWT nichts zu suchen.
Registrierte und eigene Claims
RFC 7519 definiert sieben registrierte Claims: iss, sub, aud, exp, nbf, iat und jti. Sie haben kurze Namen und eine feste Bedeutung, und JWT-Bibliotheken prüfen exp, nbf und aud automatisch. Alles andere sind eigene Claims, angelegt von der Anwendung oder dem Identity Provider, etwa roles, scope, email oder realm_access in Keycloak. In der Claim-Tabelle steht bei jedem bekannten Claim eine kurze Erklärung.
Dekodieren ist nicht Validieren
Den Payload zu lesen beweist nichts über das Token. Jeder kann ein JWT mit einem Admin-sub und einem exp in zehn Jahren bauen. Die Echtheit kommt von der Signatur, und prüfen muss sie das Backend, immer mit dem in der Konfiguration festgelegten Algorithmus statt mit dem, was im Header steht. Nutze die Prüfung auf dieser Seite zum Debuggen, nie als Ersatz für die Validierung auf dem Server.
Das Risiko von alg none
Der Wert "none" in alg steht für ein Token ohne Signatur. Einige alte Bibliotheken akzeptierten solche Tokens, wenn der Header es verlangte, und ein Angreifer musste nur alg ändern und die Signatur löschen, um sich als beliebiger Nutzer auszugeben. Findet dieses Tool alg none, zeigt es eine Warnung. Akzeptiert deine API ein solches Token, behandle das als Sicherheitslücke.
JWS und JWE: signiert oder verschlüsselt
Fast jedes JWT, das einem begegnet, ist ein JWS: signiert, dreiteilig und mit lesbarem Payload. Das JWE ist die verschlüsselte Variante mit fünf Teilen, und lesen kann es nur, wer den Entschlüsselungsschlüssel hat. Fügst du hier ein JWE ein, weist das Tool darauf hin und zeigt nur den Header, der lesbar bleibt.
Wo du das Token zum Einfügen findest
- Im Header Authorization: Bearer einer Anfrage, im Network-Tab der DevTools oder in Postman und Insomnia
- In einem Session-Cookie, im Application-Tab der DevTools (das Cookie kann HttpOnly und für JavaScript unsichtbar sein)
- In der Antwort des Token-Endpoints des Anbieters, in den Feldern access_token und id_token
- In Logs von API-Gateway und Anwendung, oft auf mehrere Zeilen verteilt
Häufige Probleme beim Debuggen von Login und Berechtigungen
Login scheitert nach einer Weile mit 401
Der Status zeigt, ob exp überschritten ist und seit wann. Läuft das Token nach wenigen Minuten ab, prüfe, ob das Frontend mit dem Refresh Token ein neues anfordert.
Angemeldeter Nutzer bekommt 403
Sieh dir den Block mit Rollen und Scopes an. Fehlt die erwartete Rolle, liegt das Problem in der Konfiguration des Anbieters oder in der Art des gesendeten Tokens (das ID-Token statt des Access Tokens zu schicken ist ein häufiger Fehler).
Token direkt nach dem Ausstellen abgelehnt
exp, iat und nbf zählen Sekunden in UTC und hängen nicht von der Zeitzone ab. Wird ein frisch ausgestelltes Token abgelehnt, liegt es meist an abweichenden Uhren zwischen Servern. Die Zeiten stehen in deiner Zeit und in UTC, damit du sie mit den Logs vergleichen kannst.
Gültiges Token wird von einer anderen API abgelehnt
Prüfe aud. Jede API sollte nur Tokens akzeptieren, die für sie ausgestellt wurden, daher funktioniert das Token einer API nicht bei einer anderen.
Häufig gestellte Fragen zum JWT Decoder
Was beim Lesen und Debuggen von JWTs oft auftaucht.