JWT-Decoder – Payload und Ablaufzeit auslesen

Deine Eingaben werden nur in diesem Browser verarbeitet und nie an einen Server gesendet. So funktioniert es

So benutzt du den Decoder

Sobald im Feld „JWT einfügen“ ein Token steht, bekommst du fünf Dinge zu sehen:

Ablaufhinweis: Enthält die Payload ein exp, steht ganz oben „Noch nicht abgelaufen“ oder „Abgelaufen“ zusammen mit dem exp-Zeitpunkt. Dieser Hinweis vergleicht nur exp mit der Geräteuhr. Er bestätigt weder den nbf-Startzeitpunkt noch die Signatur.
Header, Payload: beide Teile als eingerücktes JSON. Über den Button neben der Überschrift kopierst du jeden Teil einzeln.
Signaturalgorithmus: der Wert von alg aus dem Header. Fehlt alg oder ist es kein String, steht dort „Nicht angegeben“.
Signature (unverändert, nicht geprüft): der dritte Abschnitt, so wie er im Token steht.
Registrierte Claims: exp (läuft ab um), iat (ausgestellt um) und nbf (gültig ab), umgerechnet in Datum und Uhrzeit. Was in der Payload fehlt, ist mit „Nicht vorhanden“ markiert.

Datum und Uhrzeit erscheinen in der Zeitzone dieses Browsers. Schreibt dein Server seine Logs in UTC, weichen die Angaben um die Zeitverschiebung ab.

Ein Beispiel zum Mitlesen

Füge dieses Token ein:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMjkyMDB9.c2lnbmF0dXJl

Als Header erscheint {"alg": "HS256", "typ": "JWT"}, als Signaturalgorithmus HS256.
Die Payload lautet {"sub": "user-42", "iat": 1767225600, "exp": 1767229200}.
iat 1767225600 ist der 1. Januar 2026, 00:00:00 (UTC), exp 1767229200 liegt eine Stunde später bei 01:00:00 (UTC). In einem Browser mit einer UTC+9-Zeitzone stehen dort 09:00:00 und 10:00:00. Beides ist längst vorbei, der Hinweis oben lautet also „Abgelaufen“.
Der dritte Abschnitt c2lnbmF0dXJl ist keine echte Signatur, sondern schlicht das Wort signature in Base64URL. Trotzdem liest das Tool das Token ohne Fehlermeldung. Daran siehst du, dass die Signatur hier überhaupt nicht geprüft wird.

Die drei Teile eines JWT

Ein JWT besteht aus drei Abschnitten, getrennt durch Punkte: header.payload.signature. Im Header stehen der Signaturalgorithmus (alg) und der Tokentyp (typ), in der Payload die Claims, zum Beispiel Nutzer-ID, Berechtigungen oder Ablaufzeitpunkt. Ein Claim ist ein Paar aus Name und Wert, das das Token mit sich trägt.

Header und Payload sind JSON, das lediglich in Base64URL umgeschrieben wurde. Verschlüsselt ist daran nichts. Wer das Token in die Hand bekommt, kann den Inhalt ohne jeden Schlüssel lesen. Landet deshalb ein Token mit E-Mail-Adresse oder internen Berechtigungen unverändert im Messenger oder im Issue-Tracker, ist dieser Inhalt gleich mit veröffentlicht. Nur der letzte Abschnitt, die Signature, wird mit dem Schlüssel des Ausstellers erzeugt. Mit ihr lässt sich feststellen, ob Header und Payload seit der Ausstellung verändert wurden.

Was das Tool nicht prüft

Die Signatur: Zum Prüfen braucht man den geheimen Schlüssel des Ausstellers (bei HMAC-Verfahren) oder seinen öffentlichen Schlüssel (bei RSA und ECDSA). Ein Feld für Schlüssel gibt es hier nicht. Dass der Inhalt ordentlich aussieht, heißt also nicht, dass das Token echt ist.
Die Uhr hinter dem Ablaufstatus: „Noch nicht abgelaufen“ und „Abgelaufen“ ergeben sich aus dem Vergleich mit der Uhr dieses Geräts. Geht sie falsch, stimmt auch der Status nicht.
Toleranz: Ab dem Moment, in dem die aktuelle Zeit exp erreicht, heißt es „Abgelaufen“, und vor nbf heißt es „Vor der Startzeit“. RFC 7519 erlaubt wegen abweichender Serveruhren eine kleine Toleranz, üblicherweise nicht mehr als ein paar Minuten. Dieses Tool rechnet ohne Toleranz. Ein Token, das dein Server noch annimmt, kann hier deshalb schon als abgelaufen erscheinen.
Alle übrigen Claims: Werte wie iss (Aussteller) oder aud (Empfänger) stehen unverändert in der Payload. Ob sie stimmen, wird nicht bewertet.

Über den tatsächlichen Zugriff entscheidet die Prüfung auf dem Server. Ein Token aus dem Produktivsystem ist für die Dauer seiner Gültigkeit ein Zutrittsausweis. Am sichersten ist es deshalb, der Warnung auf dem Bildschirm zu folgen und solche Token nicht in Online-Tools einzufügen.

exp, iat und nbf richtig lesen

RFC 7519 schreibt für diese drei Claims vor, dass der Wert die Sekunden seit dem 1. Januar 1970, 00:00:00 (UTC) angibt. Das Format heißt NumericDate. Das Tool rechnet nur dann in ein Datum um, wenn der Wert eine Zahl ist.

Steht der Wert als String in Anführungszeichen da, etwa "exp": "1767229200", wird er nicht als Datum gelesen, und es erscheint „Nicht vorhanden“. Im JSON der Payload siehst du den Wert trotzdem. Wenn ein Claim vorhanden ist und trotzdem „Nicht vorhanden“ dasteht, schau nach den Anführungszeichen.
Auch Zahlen, die für ein JavaScript-Datum zu groß sind, führen zu „Nicht vorhanden“.
Einen Status bekommen nur exp und nbf. Bei iat steht allein die Uhrzeit.

Wenn sich das Token nicht lesen lässt

Fehlermeldung	Häufige Ursache
Ein JWT braucht drei durch Punkte getrennte Teile (header.payload.signature), hier sind es aber N.	Das Token wurde nur teilweise kopiert. Verschlüsselte Token (JWE) haben fünf Abschnitte und lassen sich mit diesem Tool nicht lesen
Der Teil “header” (oder “payload”) ließ sich nicht als Base64URL lesen.	Vorn steht noch „Bearer “, mittendrin steckt ein Zeilenumbruch, oder es ist gewöhnliches Base64 mit `+`, `/` oder `=`
Der Teil “header” (oder “payload”) wurde dekodiert, ist aber kein gültiges JSON.	Es ist gar kein JWT, sondern irgendein anderer Wert, der mit Punkten zusammengesetzt wurde

Base64URL ist Base64, bei dem + und / durch - und _ ersetzt sind und das = am Ende wegfällt. Enthält ein Abschnitt etwas anderes als A–Z, a–z, 0–9, - und _, liest das Tool ihn nicht.

Häufige Fragen

Kann ich den Authorization-Header komplett einfügen, also mit „Bearer “ davor?

Nein. Steht vor dem Token noch etwas anderes, etwa „Bearer eyJ...“, erscheint die Meldung „Der Teil "header" ließ sich nicht als Base64URL lesen.“ Füge nur das Token selbst ein, also alles ab eyJ. Leerzeichen und Zeilenumbrüche vor und nach dem Token stören nicht. Steckt aber mitten im Token ein Zeilenumbruch oder ein Leerzeichen, kommt dieselbe Meldung.

exp ist eindeutig eine Zahl, angezeigt wird aber ein Datum in zigtausend Jahren. Woran liegt das?

Dann stehen in exp Millisekunden statt Sekunden. Das Tool liest den Wert so, wie der Standard es vorsieht, nämlich als Sekunden. Aus 1767229200 (1. Januar 2026) wird in Millisekunden 1767229200000, und das ergibt ein Datum im Jahr 57971 mit dem Status „Noch nicht abgelaufen“. Die Stelle, die das Token ausstellt, muss die Millisekunden in Sekunden umrechnen, bevor sie den Wert hineinschreibt.

Was sehe ich bei einem Token ohne exp?

Der Ablaufhinweis oben entfällt, und bei exp steht „Nicht vorhanden“. Gibt es ein nbf, zeigt nur dieses Feld „Vor der Startzeit“ oder „Startzeit erreicht“. Bei iat erscheint nur die Uhrzeit.

Ich habe ein Token gesehen, in dessen Header alg auf „none“ steht. Ist das gefährlich?

Mit alg none braucht ein Token keine Signatur, und damit kann jeder eines mit beliebigem Inhalt bauen. Das Tool liest auch solche Token ganz normal aus und blendet unter „Signaturalgorithmus“ eine Warnung ein. Nimmt ein Server so ein Token an, kann die Authentifizierung umgangen werden. Prüfe deshalb, ob dein Verifizierungscode alg none ausdrücklich ablehnt.