Zum Inhalt springen

JWT dekodieren und verifizieren

Dekodieren Sie Header und Claims eines JSON Web Tokens, prüfen Sie das Ablaufdatum und verifizieren Sie die Signatur. Das Token verlässt Ihren Browser nicht.

Wird in diesem Tab decodiert und geprüft – Token und Schlüssel werden nirgendwohin gesendet.

Header, Claims und Ablaufzeit erscheinen hier, sobald Sie ein Token einfügen.
Läuft in Ihrem Browser · kein UploadSo funktioniert's

So verwenden Sie JWT-Decoder

  1. 1

    Token einfügen

    Fügen Sie das JWT aus einem Authorization-Header, einem Cookie oder dem Speicher Ihrer App ein; ein vorangestelltes „Bearer“ wird ignoriert.

  2. 2

    Claims lesen

    Sehen Sie sich die Tabellen für Header und Payload, die lesbaren Zeiten für exp, iat und nbf sowie den Hinweis zur Ablaufzeit an.

  3. 3

    Schlüssel hinzufügen

    Geben Sie das HMAC-Secret ein oder fügen Sie den öffentlichen Schlüssel als PEM, Zertifikat, JWK oder JWKS ein.

  4. 4

    Signatur prüfen

    Klicken Sie auf „Signatur prüfen“, um zu bestätigen, dass der Token mit diesem Schlüssel signiert und nicht verändert wurde.

Limits und Pro

Kostenlos, ohne Registrierung und ohne Begrenzung der Tokenanzahl; die Prüfung unterstützt 13 Algorithmen (HS, RS, PS und ES mit 256, 384 und 512 Bit sowie EdDSA).

Pro entfernt die Werbung; Decodierung und Prüfung sind in jedem Tarif gleich. Pro ansehen

Über JWT-Decoder

Ein JSON Web Token besteht aus drei Base64URL-Zeichenfolgen, die durch Punkte verbunden sind: einem Header mit dem Signaturalgorithmus, einem Payload mit Claims und einer Signatur. Fügen Sie einen Token ein – mit oder ohne das Präfix „Bearer“ – und der Decoder zeigt Header und Payload als lesbare Tabelle oder formatiertes JSON an, färbt die drei Teile des Tokens ein und erklärt Standardfelder wie iss, sub, aud, kid und scope.

Zeit-Claims werden für Sie umgerechnet: exp, iat, nbf und auth_time erscheinen als Datum in Ihrer Zeitzone, in UTC und als relative Angabe („läuft in 2 Stunden ab“, „vor 3 Tagen abgelaufen“). Ein Hinweis zeigt auf einen Blick, ob der Token abgelaufen, noch nicht gültig oder ohne Ablaufzeit ist, und warnt, wenn exp offenbar in Millisekunden statt in Sekunden angegeben ist.

Das Decodieren beweist nichts darüber, wer einen Token ausgestellt hat. Deshalb prüft die Verifizierung die Signatur mit der integrierten WebCrypto-Funktion Ihres Browsers. HS256, HS384 und HS512 benötigen das gemeinsame Secret (als Klartext oder Base64). RS-, PS- und ES-Algorithmen mit 256, 384 und 512 Bit sowie EdDSA mit Ed25519 benötigen den öffentlichen Schlüssel. Sie können ihn als öffentlichen PEM-Schlüssel, als RSA-PUBLIC-KEY-Block, als X.509-Zertifikat, als einzelnen JWK oder als vollständiges JWKS einfügen; dabei wird der Schlüssel anhand der kid des Tokens ausgewählt.

Das Tool kann keine JWE-Tokens (die fünfteilige Variante) entschlüsseln und ruft keine JWKS-URLs ab. Öffnen Sie die jwks_uri des Ausstellers selbst und fügen Sie deren JSON ein.

Datenschutz

Tokens sind Zugangsdaten, und diese Seite behandelt sie auch so: Decodierung und Signaturprüfung laufen in Ihrem Browser mit WebCrypto. Token, Secret und Schlüssel werden weder an einen Server gesendet noch protokolliert oder gespeichert. Beim Schließen oder Neuladen des Tabs wird alles gelöscht.

Funktionen

Lesbare Zeiten

exp, iat und nbf in Ihrer Zeitzone, in UTC und als „in 2 Stunden“ oder „vor 3 Tagen“.

Echte Signaturprüfung

HMAC, RSA, RSA-PSS, ECDSA und Ed25519 werden mit WebCrypto gegen Ihren Schlüssel oder Ihr JWKS geprüft.

Token bleibt lokal

Es wird nichts hochgeladen, daher können Produktions-Tokens sicher untersucht werden.

JWT-Decoder: Häufig gestellte Fragen

Ist es sicher, hier einen Produktions-Token einzufügen?
Der Token wird von JavaScript in Ihrem Tab decodiert und geprüft, und es wird keine Anfrage mit dem Token gesendet. Das können Sie im Netzwerk-Panel Ihres Browsers nachprüfen. Dennoch funktioniert ein gültiger Token bis zum Ablauf wie ein Passwort. Fügen Sie aktive Tokens daher nicht auf Seiten ein, denen Sie nicht vertrauen, und verwenden Sie für Screenshots lieber abgelaufene oder Test-Tokens.
Warum beweist ein decodierter Token nichts?
Jeder kann Header und Payload erstellen und per Base64URL codieren; das Decodieren kehrt das nur um. Erst die Signatur verbindet den Token mit dem Aussteller. Prüfen Sie sie mit dem öffentlichen Schlüssel des Ausstellers oder dem gemeinsamen Secret, bevor Sie einem Claim vertrauen. Achten Sie außerdem darauf, dass alg dem entspricht, was Ihr Server erwartet: „none“ oder einen ausgetauschten Algorithmus zu akzeptieren, ist eine klassische Schwachstelle.
Wo finde ich den öffentlichen Schlüssel für einen RS256- oder ES256-Token?
Identitätsanbieter veröffentlichen ihre Schlüssel als JWK Set. Rufen Sie die /.well-known/openid-configuration des Ausstellers auf, öffnen Sie die dort genannte jwks_uri und fügen Sie das JSON hier ein; verwendet wird der Schlüssel, dessen kid zum Token-Header passt. Sie können auch einen öffentlichen PEM-Schlüssel oder das X.509-Zertifikat des Ausstellers einfügen.
Was bedeuten exp, iat und nbf?
Das sind NumericDate-Claims, gezählt in Sekunden seit dem 1. Januar 1970 UTC. exp gibt an, wann der Token ungültig wird, iat, wann er ausgestellt wurde, und nbf, ab wann er frühestens akzeptiert werden darf. Server erlauben meist ein bis zwei Minuten Abweichung der Uhrzeit. Der Decoder zeigt jeden Wert als lokales Datum, als UTC-Zeitstempel und als relative Zeitangabe.
Warum schlägt die Prüfung trotz richtigem HMAC-Secret fehl?
Häufige Ursachen sind mit dem Secret kopierte Leerzeichen, ein Secret, das beim Signieren Base64-codiert war, oder ein Token, den ein Tool neu codiert und dabei die Bytes von Header oder Payload verändert hat. Probieren Sie die Option „Secret ist Base64-codiert“ aus. Jede Änderung an den ersten beiden Teilen, selbst eine andere Reihenfolge der JSON-Schlüssel, macht die Signatur ungültig.
Alle: entwickler-tools