JWT Decoder
Die Claims eines Tokens lesen — und seine Signatur beweisen · läuft in diesem Tab, wird nie irgendwohin gesendet
Token
Signatur
Ein JWT ist codiert, nicht verschlüsselt — wer dieses Token hat, kann alles darüber ohne Schlüssel lesen. Erst eine Signaturprüfung sagt dir, dass es echt und unverändert ist.
Claims
Füge ein Token in das Token-Panel ein, dann erscheinen seine Claims hier — in verständlichen Worten.
Header
Payload
So funktioniert der JWT Decoder
Ein JWT-Decoder, der ein Token in seine drei Teile zerlegt, Header und Payload dekodiert und jeden Claim in Klartext auflistet — Ablauf, „nicht vor“ und Ausstellungszeit als echte Daten statt als Sekunden seit 1970. Er verifiziert auch die Signatur: Füge das gemeinsame Secret für ein HS-Verfahren oder einen öffentlichen Schlüssel für RS, PS oder ES ein, und die Prüfung läuft über die WebCrypto deines eigenen Browsers. Weder Token noch Schlüssel werden je hochgeladen, und der Schlüssel wird nicht einmal in diesem Browser gespeichert.
Füge ein Token ein — mit oder ohne Bearer-Präfix — und es wird in seine drei Teile zerlegt, farblich getrennt, sodass du siehst, wo jeder endet. Header und Payload werden zu JSON decodiert, und die Claims werden noch einmal in verständlichen Worten aufgelistet: exp, nbf und iat als echte Daten und dazu, wie lange es her ist oder wie weit es hin ist.
Ein JWT zu decodieren heißt nicht, es zu verifizieren. Die ersten beiden Teile sind base64url, keine Verschlüsselung: wer das Token hat, kann sie lesen — deshalb gehört in ein Token nie ein Geheimnis. Schalte Signatur prüfen ein und füge das gemeinsame Secret für ein HS-Verfahren oder einen öffentlichen Schlüssel für RS, PS oder ES ein, dann wird die Signatur wirklich geprüft — HS256/384/512, RS256/384/512, PS256/384/512 und ES256/384/512, über die WebCrypto des Browsers selbst.
Der Schlüssel, den du einfügst, wird anders behandelt als jede andere Eingabe auf dieser Seite: Er wird nie in den localStorage geschrieben und beim Neuladen nicht wiederhergestellt. Nichts davon — weder Token noch Schlüssel — wird hochgeladen, und es gibt keinen Server, der beides empfangen könnte.
Häufige Fragen
Ist es sicher, ein echtes JWT in diesen Decoder einzufügen?
Ja. Das Token wird von JavaScript in deinem eigenen Tab dekodiert, und es gibt kein Backend, an das es gehen könnte — trenne die Netzwerkverbindung, und der Decoder arbeitet weiter. Bei JWTs zählt das mehr als bei fast allen anderen Daten: Ein Token ist eine aktive Zugangsberechtigung, und wer es auf einer Seite einfügt, die es an einen Server schickt, gibt alles preis, was es gewährt.
Heißt dekodiert auch gültig?
Nein, und der Unterschied ist wesentlich. Header und Payload sind base64url-codiert, nicht verschlüsselt — wer das Token hat, kann sie lesen. Deshalb gehört in ein JWT nie ein Geheimnis. Erst die Prüfung der Signatur gegen den richtigen Schlüssel sagt dir, dass das Token echt und unverändert ist und dass man seinen Claims trauen kann.
Welche Signaturverfahren kann er prüfen?
HS256, HS384 und HS512 mit einem gemeinsamen Secret sowie RS256/384/512, PS256/384/512 und ES256/384/512 mit einem öffentlichen Schlüssel als PEM-Block, einzelnem JWK oder ganzem JWKS — dann wählt die kid des Tokens den passenden Schlüssel aus. Die Prüfung nutzt die eingebaute WebCrypto des Browsers, es wird also kein Schlüsselmaterial irgendwohin gesendet.
Wird mein Signaturschlüssel oder Secret gespeichert?
Nein. Alle anderen Werkzeuge hier sichern deine Eingabe im localStorage, damit ein Neuladen die Arbeit nicht verliert; der Prüfschlüssel ist davon bewusst ausgenommen. Er bleibt im Arbeitsspeicher, wird für die Prüfung benutzt und ist fort, sobald du die Seite verlässt.
Warum wird mein Token als abgelaufen angezeigt?
Der exp-Claim ist ein NumericDate — Sekunden seit 1970 — und der Decoder zeigt ihn als echtes Datum samt der Angabe, wie lange er schon vorbei ist. Ein abgelaufenes Token ist die häufigste Ursache für ein plötzliches 401 von einer API, die eben noch funktionierte. Ein nbf-Claim in der Zukunft bewirkt dasselbe am anderen Ende.