JWT-Decoder

So dekodieren Sie ein JWT

1. Fügen Sie das Token in Token ein. Eine ganze Zeile Authorization: Bearer eyJ… funktioniert, ebenso umgebende Anführungszeichen oder ein über mehrere Zeilen umbrochenes Token.
2. Lesen Sie das Ergebnis. Die drei Teile werden in unterschiedlichen Farben gezeigt, Header und Payload werden formatiert, und Claims listet jeden Claim mit seiner Bedeutung. Zeiten wie exp und iat erscheinen als Ortszeit, UTC und relative Zeit im Stil von „läuft in 1 Stunde ab“.
3. Um die Signatur zu prüfen, fügen Sie unter Signatur prüfen das gemeinsame Secret oder den öffentlichen Schlüssel ein. Die Feldbezeichnung richtet sich nach dem alg des Tokens: Secret bei HS256/384/512, Öffentlicher Schlüssel bei allen anderen.
4. Lesen Sie die Warnungen. Das Tool markiert alg: none, abgelaufene Tokens, ein nbf in der Zukunft, ein fehlendes exp, Zeiten in Millisekunden sowie Header, die auf entfernte Schlüssel verweisen (jku, x5u) oder einen eigenen Schlüssel einbetten (jwk).

Sie können ein Token auch direkt über einen Link wie /jwt-decoder/#token=eyJ… öffnen. Der Teil nach # ist ein URL-Fragment, und Browser senden Fragmente nie an den Server.

Was in einem Token steckt

Ein signiertes JWT (ein JWS in kompakter Form) besteht aus drei Base64URL-Zeichenketten, verbunden durch Punkte: header.payload.signature. Hier ein echtes HS256-Token, ausgestellt am 1. Januar 2026 und eine Stunde gültig:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyLTQyIiwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMjkyMDB9.U3Gb12hN5Fnpi1rJ7nrkUzIEidkg-hPnbgiIpTah3R4

Der erste Teil ergibt dekodiert den Header {"alg":"HS256","typ":"JWT"}. Der zweite ist die Payload:

{"iss":"https://auth.example.com","sub":"user-42","aud":"api.example.com","iat":1767225600,"exp":1767229200}

Der dritte Teil sind 32 Bytes HMAC-SHA256, berechnet über die ersten beiden Teile; ändert sich ein einziges Zeichen in Header oder Payload, stimmt er nicht mehr. Fast jedes JWT beginnt mit eyJ, dem Base64 von {". Die Teile verwenden das URL-sichere Alphabet (- und _) ohne =-Padding; Wie JWT Base64URL nutzt zeigt, wie man eines von Hand dekodiert.

JWS oder JWE: signierte und verschlüsselte Tokens

Die meisten JWTs sind JWS: signiert und für jeden lesbar. Ein JWE ist verschlüsselt und hat fünf statt drei Teile: header.encrypted_key.iv.ciphertext.tag. Sein Header bleibt lesbar und nennt den Algorithmus für die Schlüsselverwaltung (alg, zum Beispiel RSA-OAEP-256 oder dir) und die Inhaltsverschlüsselung (enc, zum Beispiel A256GCM).

Fügen Sie hier ein JWE ein, dekodiert das Tool diesen Header, zeigt alg, enc und kid und markiert die Payload als verschlüsselt. Zum Entschlüsseln braucht man den privaten Schlüssel des Empfängers oder den gemeinsamen Schlüssel, und dieses Tool entschlüsselt kein JWE. Brauchen Sie ein Token, dessen Payload Nutzer nicht lesen können, ist JWE das richtige Format; Geheimnisse in die Payload eines JWS zu schreiben ist dasselbe, wie sie im Klartext abzulegen, wie Base64 ist keine Verschlüsselung erklärt.

Übersicht der JWT-Claims

Die ersten sieben Zeilen sind die registrierten Claims aus RFC 7519; die übrigen sind in Tokens von OpenID Connect und OAuth verbreitet. Jeder Zeitwert ist ein NumericDate: ganze Sekunden seit dem 01.01.1970 UTC, nie Millisekunden.

Der Header hat eigene Parameter: alg (der Signaturalgorithmus), typ (meist JWT, oder at+jwt bei OAuth-Access-Tokens), kid (welcher Schlüssel signiert hat) und cty (auf JWT gesetzt, wenn ein Token in einem anderen verschachtelt ist).

Die Signatur prüfen: welchen Schlüssel einfügen

Nur die Signaturprüfung zeigt, woher ein Token stammt. Welchen Schlüssel sie braucht, hängt von der Algorithmusfamilie im Header ab.

Bei Tokens von einem Identity Provider liegen die öffentlichen Schlüssel unter der jwks_uri, die in https://<issuer>/.well-known/openid-configuration aufgeführt ist. Diese Seite kann die URL nicht abrufen, weil sie keine Verbindung zu anderen Servern aufbauen kann. Öffnen Sie sie daher in einem neuen Tab und fügen Sie das JSON ein. Bei einem JWKS wird der Schlüssel anhand der kid gewählt; hat das Token keine kid, wird jeder kompatible Schlüssel probiert.

ECDSA-Signaturen in DER-Form (bei ES256 meist 70 bis 72 Bytes statt 64) werden erkannt, umgewandelt und markiert, weil JWS rohes r‖s verlangt und viele Bibliotheken DER ablehnen. Ein eingefügter privater Schlüssel funktioniert ebenfalls (die öffentliche Hälfte wird abgeleitet), auch wenn man zum Prüfen nie einen braucht. ES256K und Ed448 werden nicht unterstützt, da WebCrypto sie nicht kennt.

Scheitert ein HS256-Token mit einem Secret, bei dem Sie sich sicher sind, ist das Secret oft irgendwo in Ihrer Konfiguration Base64-kodiert, und der Server dekodiert es vor der Verwendung. Stellen Sie Secret als auf Base64 und versuchen Sie es erneut.

Warum das Dekodieren eines Tokens hier sicher ist

Ein JWT in einem Authorization-Header ist bis zu seinem Ablauf eine funktionierende Zugangsberechtigung. Fügen Sie ein aktives Produktions-Token in eine Webseite ein, die es an einen Server schickt, kann der Betreiber dieses Servers es gegen Ihre API wiederverwenden, und von außen können Sie meist nicht erkennen, ob eine Seite das tut.

Auf dieser Seite laufen das Dekodieren und die Signaturprüfung mit WebCrypto in Ihrem Browser. Die Seite hat außerdem eine Content Security Policy, deren connect-src nur /cdn-cgi/rum erlaubt, wo Cloudflare Web Analytics die Seitenaufrufe zählt. Jede andere fetch-, XHR-, WebSocket- und Beacon-Anfrage, die die Seite versuchen könnte, blockiert der Browser. Sie können das selbst nachprüfen: Öffnen Sie in den Entwicklertools den Netzwerk-Tab und fügen Sie ein Token ein, oder schalten Sie nach dem Laden der Seite das WLAN ab und dekodieren Sie weiter.

Verwenden Sie trotzdem lieber Test-Tokens oder Tokens, die bald ablaufen. Wurde ein Produktions-Token irgendwo eingefügt, das Sie nicht kontrollieren, widerrufen Sie die Sitzung.

Abgelaufene Tokens, nbf und Uhrenabweichung

exp und nbf werden mit der Uhr des Prüfers verglichen, und Uhren driften. Ein Token von einem Server, dessen Uhr 30 Sekunden vorgeht, kann mit iat und nbf in der Zukunft ankommen und als „noch nicht gültig“ abgelehnt werden. JWT-Bibliotheken akzeptieren daher eine kleine Toleranz: leeway in PyJWT, clockTolerance in jsonwebtoken und jose.

Dieser Decoder vergleicht die Zeiten mit der Uhr Ihres Geräts und beschreibt das Ergebnis in Worten: „vor 2 Tagen abgelaufen“ bei exp, „noch nicht gültig“ mit der verbleibenden Zeit bei nbf, oder eine Warnung, dass iat in der Zukunft liegt, was auf die Uhr des Ausstellers hindeutet. Ein Wert wie 1767229200000 wird als Millisekunden markiert; als Sekunden gelesen läge er Zehntausende Jahre in der Zukunft, ein häufiger Fehler, wenn Code Date.now() statt Math.floor(Date.now() / 1000) verwendet.

Um die Claims im Code ohne Prüfung zu lesen, genügt die Standardbibliothek von Python:

import base64, json

def b64url_decode(part):
    return base64.urlsafe_b64decode(part + "=" * (-len(part) % 4))

header_b64, payload_b64, signature_b64 = token.split(".")
print(json.loads(b64url_decode(payload_b64)))

In Node.js leistet JSON.parse(Buffer.from(payload_b64, "base64url").toString("utf8")) dasselbe. Für Autorisierungsentscheidungen verwenden Sie eine Bibliothek, die die Signatur prüft und die akzeptierten Algorithmen festlegt. Weitere Snippets stehen auf den Seiten zu Python und Node.js.

Um ein Token zum Testen zu erstellen oder neu zu signieren, nutzen Sie den JWT-Encoder. Ein einzelnes Segment lässt sich mit dem Base64URL-Decoder für sich dekodieren.

Häufige Fragen