Ein JWT untersuchen und seine Signatur mit einem HMAC-Secret oder einem öffentlichen JWK beziehungsweise JWKS prüfen. Erwarteten Aussteller oder Zielgruppe bei Bedarf mitprüfen; das bloße Dekodieren bestätigt die Echtheit des Tokens nicht.
Läuft lokal in deinem BrowserGeben Sie für HS256/384/512 das unveränderte gemeinsame Geheimnis ein. Fügen Sie für asymmetrische Algorithmen ein öffentliches JWK oder ein JWKS-JSON-Dokument ein.
Decode or verify a compact JWT to inspect its protected header and payload.
Jeder kann einen JWT-Payload dekodieren. Vertrauen Sie einem Token erst nach erfolgreicher Signaturprüfung mit vorgesehenem Algorithmus und Schlüssel sowie der Validierung von Issuer, Audience, Zeitangaben und anwendungsspezifischen Claims.
Ein kompaktes JWT einfügen: das Werkzeug zeigt den geschützten Header und die Payload und prüft anschließend die Signatur mit dem Material, das Sie liefern — ein rohes gemeinsames Geheimnis für HS256/384/512 oder ein öffentliches JWK- bzw. JWKS-Dokument für RS, PS, ES und EdDSA. Erwarteter Aussteller und erwartete Audience lassen sich im selben Durchlauf prüfen.
Dekodieren ist nicht Verifizieren. Die Seite dekodiert lokal und sagt das auch, und sie meldet ein Token erst dann als verifiziert, wenn Signatur und registrierte Claims (exp, nbf, iss, aud) bestehen. Nichts wird hochgeladen, keine JWKS-URL abgerufen und kein Schlüsselmaterial gespeichert.
Inspect token schickt die Payload durch einen JWT-Decoder und gibt geschützten Header und Payload als JSON aus. Die Statuszeile bleibt bewusst eine Warnung: Wer das Token hat, kann es lesen, dekodierte Claims sind also nur eine Vorschau dessen, was das Token zu sein behauptet.
Ein Token ohne signiertes Verfahren (alg none oder fehlend) wird hier weiterhin dekodiert: Die Ansicht verlangt keine Signatur. Erst die Signaturprüfung lehnt es ab.
Mit einem gemeinsamen Geheimnis wird die Signatur über den exakten Tokentext neu berechnet und verglichen; mit einem öffentlichen Schlüssel wird das passende JWK importiert und verwendet. In einem JWKS-Dokument wird der Schlüssel gesucht, dessen kid zum Token-Header passt; trägt das Token kein kid, wird der erste Schlüssel genommen.
Die registrierten Claims werden im selben Durchlauf geprüft: exp und nbf gegen die aktuelle Uhr, iss gegen den erwarteten Aussteller und aud gegen die erwartete Audience, sofern diese Felder gefüllt sind. Die Statuszeile benennt den ersten Fehler — fehlgeschlagene Signaturprüfung, exp- oder nbf-Prüfung, unerwarteter oder fehlender iss- oder aud-Wert — statt einer allgemeinen Meldung.
Die Übersicht listet Algorithm, Key ID, Issuer, Audience, Subject und Expires; ein Audience-Array erscheint als kommagetrennte Liste. Das Feld darunter zeigt das dekodierte Token als eingerücktes JSON mit protectedHeader und payload in einem Dokument.
Beide Bereiche sind schreibgeschützter Text: das Ergebnis lässt sich markieren und kopieren, und ein erfolgreicher Lauf behält dasselbe Layout wie eine Inspektion — nichts verdeckt, dass die Signatur der Teil ist, der die Claims vertrauenswürdig macht.
Alles läuft im Tab mit der jose-Bibliothek und der Web Crypto API. Die Seite stellt beim Prüfen keine Anfrage, ruft nie eine JWKS-URL ab — das Dokument fügen Sie ein — und das Schlüsselmaterial bleibt in den Formularfeldern.
Der Beispiel-Knopf ist der einzige Ort, an dem ein privater Schlüssel existiert, und er verlässt die Seite nicht: Das Paar entsteht im Browser, das Token wird dort signiert, und das Feld erhält nur das öffentliche JWK. Das heißt zugleich: Schlüsselwechsel sind hier manuell — ein rotiertes JWKS muss erneut eingefügt werden.