JWT abgelaufen? Ablaufzeit (exp) richtig prüfen

Ein JWT ist abgelaufen, sobald die aktuelle Zeit gleich oder später als sein exp-Claim ist. exp ist eine Anzahl Sekunden seit dem 1. Januar 1970 UTC: 1793372400 steht für den 30. Oktober 2026, 15:00:00 UTC, also 16:00 Uhr in Berlin. Zum Prüfen dekodieren Sie den mittleren Teil des Tokens, lesen exp und vergleichen den Wert mit der Uhr. Unser kostenloser JWT-Decoder erledigt das für Sie. Token einfügen, und er zeigt Abgelaufen oder Nicht abgelaufen, dazu das genaue Datum in Ihrer Zeitzone und in UTC.

Er ist kostenlos, braucht kein Konto und läuft komplett in Ihrem Browser. Bei unserem Test am 31. Oktober 2026 hat die Seite keine einzige Anfrage mit dem Token gesendet. Gäste haben 5 Tool-Nutzungen pro Tag, und ein kostenloses My-Botsy-Konto (100 % kostenlos, kein Spam) hebt dieses Tageslimit auf. Alle zitierten Ergebnisse sind echt. Die Decoder-Ausgaben stammen aus Tests auf mybotsy.com am 31. Oktober 2026, die Bibliotheksergebnisse aus PyJWT 2.15.1, jsonwebtoken 9.0.3 und jose 6.2.14, am selben Tag ausgeführt.

Was der exp-Claim bedeutet

RFC 7519, der JWT-Standard, definiert drei Zeit-Claims. Alle drei sind optional, und alle drei sind NumericDate-Werte, also Sekunden und keine Millisekunden.

• exp (Expiration Time): Ab diesem Zeitpunkt, einschließlich, darf das Token nicht mehr akzeptiert werden.
• nbf (Not Before): Vor diesem Zeitpunkt darf es ebenfalls nicht akzeptiert werden.
• iat (Issued At): der Ausstellungszeitpunkt. Er macht allein nichts ungültig, verrät aber das Alter des Tokens.

Für exp und nbf erlaubt die RFC einen kleinen Spielraum, „normalerweise nicht mehr als ein paar Minuten“, um Abweichungen zwischen Uhren auszugleichen. Deshalb können zwei Systeme bei einem Token, das vor ein paar Sekunden abgelaufen ist, zu unterschiedlichen Ergebnissen kommen.

JWT-Ablaufzeit prüfen: Schritt für Schritt

1. Token kopieren. Das ist die lange Zeichenkette mit zwei Punkten, meist nach Authorization: Bearer im Request-Header oder in einem Cookie bzw. im localStorage.
2. In den JWT-Decoder einfügen. Vorher aufräumen ist nicht nötig: Das Tool entfernt Authorization:, Bearer, Anführungszeichen, Leerzeichen und Zeilenumbrüche und weist darauf hin.
3. Die Zeile Status lesen. Sie zeigt Abgelaufen, Nicht abgelaufen, Noch nicht gültig (wenn nbf in der Zukunft liegt), Kein Ablaufdatum (kein exp) oder Ablauf nicht lesbar: exp ist keine gültige Zahl (wenn exp vorhanden, aber keine Zahl ist).
4. Die Zeile Läuft ab (exp) prüfen. Sie enthält das Datum in Ihrer Zeitzone, denselben Zeitpunkt in UTC, eine relative Angabe („gestern“, „in 2 Monaten“) und den Rohwert.
5. Auf die Gültigkeitsdauer achten. Das ist exp minus iat. Lebt ein Access-Token 30 Tage, liegt das Problem bei der Ausstellung der Tokens, nicht bei diesem einen Token.
6. Die Hinweise lesen. Der Decoder warnt bei Zeitangaben in Millisekunden, bei alg: none und bei Tokens mit Padding. Außerdem erinnert er daran, dass er die Signatur nicht prüft.

Durchgerechnete Beispiele (echte Decoder-Ausgabe)

Diese Testtokens haben wir mit HS256 und einem Wegwerf-Demo-Secret signiert. Eingefügt haben wir sie am 31. Oktober 2026 gegen 15:07 UTC in mybotsy.com/de/jwt-decoder, mit einem Browser auf Berliner Zeit.

Beispiel 1: ein abgelaufenes Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzg4NDEiLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJvcmRlcnMtYXBpIiwiaWF0IjoxNzkzMzY4ODAwLCJleHAiOjE3OTMzNzI0MDB9.FJV2oXvW0F-Q7x6rzZRKosQG_DhxLQXXz87wW-Ctq60

Alle drei Bibliotheken waren sich einig. PyJWT warf ExpiredSignatureError: Signature has expired, jsonwebtoken TokenExpiredError: jwt expired mit expiredAt 2026-10-30T15:00:00.000Z, und jose lieferte ERR_JWT_EXPIRED.

Beispiel 2: ein gültiges Token samt Header-Zeile

Eingefügt haben wir die komplette Zeile Authorization: Bearer eyJhbGciOiJIUzI1NiIs…. Der Decoder meldete „Die Eingabe wurde vor dem Dekodieren bereinigt“ und zeigte Nicht abgelaufen, mit exp am Freitag, 1. Januar 2027 um 01:00:00 MEZ = 2027-01-01T00:00:00Z („in 2 Monaten“) und einer Gültigkeitsdauer von 61 Tage 9 Stunden. Achten Sie auch auf die Zeitzonenkürzel: Ein Token mit iat 1790856000 zeigte „Donnerstag, 1. Oktober 2026 um 14:00:00 MESZ“. Die Sommerzeit endete am 25. Oktober 2026: Davor liegt Berlin zwei Stunden vor UTC, danach nur noch eine. Wer Rohwerte im Kopf umrechnet, liegt rund um die Zeitumstellung schnell eine Stunde daneben.

Beispiel 3: noch nicht gültig

Ein Token mit nbf 1796083200 und exp 1796169600 ergab Noch nicht gültig, mit Gültig ab Dienstag, 1. Dezember 2026 um 01:00:00 MEZ (2026-12-01T00:00:00Z). PyJWT meldete ImmatureSignatureError, jsonwebtoken NotBeforeError: jwt not active. Wird ein frisch ausgestelltes Token abgelehnt, prüfen Sie zuerst nbf und die Serveruhr, bevor Sie dem Ablauf die Schuld geben.

Beispiel 4: gar kein exp

Der Payload {"sub":"svc-reporting","iat":1790856000} ergab Kein Ablaufdatum (kein exp), und alle drei Bibliotheken akzeptierten ihn. Gerät so ein Token in falsche Hände, funktioniert es, bis der Schlüssel getauscht wird. Mit options={"require": ["exp"]} in PyJWT wurde daraus MissingRequiredClaimError: Token is missing the "exp" claim.

Fallstricke, die zu falschen Ergebnissen führen

exp in Millisekunden

Der Klassiker ist, Date.now() direkt in exp zu schreiben. Wir haben ein Token mit "exp":1793462400000 signiert. Der Decoder warnte „Der Wert von exp sieht nach Millisekunden aus“ las den Wert als Millisekunden und zeigte das echte Datum, den 31. Oktober 2026 um 16:00 UTC, mit dem richtigen Status und der richtigen Gültigkeitsdauer. jsonwebtoken und jose haben es akzeptiert, praktisch läuft es also nie ab. PyJWT hat es abgelehnt, allerdings wegen seiner iat-Prüfung („The token is not yet valid (iat)“), nicht wegen exp. Die Lösung: Teilen Sie beim Ausstellen durch 1000 und multiplizieren Sie mit 1000, wenn Sie aus exp ein JavaScript-Date bauen.

exp als String

"exp":"1798761600" in Anführungszeichen verstößt gegen den Standard. jsonwebtoken lehnte mit invalid exp value ab, jose mit "exp" claim must be a number. PyJWT akzeptierte den Wert und wendete ihn trotzdem an: Ein abgelaufenes Datum als String löste ExpiredSignatureError aus. Dasselbe Token besteht also in einem Dienst und scheitert im nächsten. Der Decoder zeigt neben dem Wert „Kein gültiges Datum: Es muss eine Anzahl von Sekunden sein.“ Dazu kommt ein Warnhinweis, und die Zeile Status zeigt Ablauf nicht lesbar: exp ist keine gültige Zahl.

Uhrenabweichung und Toleranz (Leeway)

Wir haben ein Token erzeugt, das seit 20 Sekunden abgelaufen war. Ohne Toleranz lehnten es alle drei Bibliotheken ab. Mit 30 Sekunden (leeway=30 in PyJWT, clockTolerance: 30 in jsonwebtoken und jose) akzeptierten es alle drei. Halten Sie die Toleranz klein: Jede zusätzliche Sekunde verlängert die Lebensdauer aller Tokens, auch gestohlener.

Dekodieren mit base64 --decode

JWTs nutzen base64url, also - und _ statt + und /. Der beliebte Einzeiler cut -d. -f2 | base64 --decode | jq .exp funktioniert nur, bis der Payload eines dieser Zeichen enthält. Unter GNU coreutils 9.7 gab ein Payload mit - das halbe JSON aus, dann base64: invalid input, und jq brach mit Unfinished string ab. Ersetzen Sie die Zeichen vorher mit tr '_-' '/+', oder fügen Sie das Token in den Decoder ein, der base64url direkt liest. Weitere Base64-Probleme behandelt Base64 dekodieren.

Dekodieren ist nicht Verifizieren

Jeder kann ein Token mit exp im Jahr 2100 schreiben. Das Auslesen von exp eignet sich zum Debuggen oder damit der Browser entscheidet, wann er erneuert. Bevor der Server einer Anfrage vertraut, muss er die Signatur prüfen, mit einer festen Liste erlaubter Algorithmen. RFC 8725 beschreibt Angriffe, bei denen der Algorithmus auf none umgestellt wurde. Unser Decoder zeigt bei alg: none eine rote Warnung.

Ablauf im Code prüfen

Diese Funktionen dienen der Anzeige oder dem Planen einer Erneuerung, nicht der Sicherheit. Getestet haben wir beide mit den Tokens oben: Das abgelaufene Token lieferte true, das gültige und das base64url-Token false, und die Tokens ohne exp oder mit exp als String lieferten kein Datum.

// JavaScript (Browser oder Node 16+)
function jwtExpiry(token) {
  const part = token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/');
  const { exp } = JSON.parse(atob(part));
  if (typeof exp !== 'number') return null;   // kein exp oder exp als String
  return new Date(exp * 1000);                 // Sekunden -> ms
}
function isExpired(token, leewaySeconds = 0) {
  const exp = jwtExpiry(token);
  return exp !== null && Date.now() >= exp.getTime() + leewaySeconds * 1000;
}

# Python 3
import base64, json, time

def jwt_exp(token):
    seg = token.split(".")[1]
    seg += "=" * (-len(seg) % 4)   # vom JWT entferntes Padding ergänzen
    exp = json.loads(base64.urlsafe_b64decode(seg)).get("exp")
    return exp if isinstance(exp, (int, float)) else None

def is_expired(token, leeway=0):
    exp = jwt_exp(token)
    return exp is not None and time.time() >= exp + leeway

Der Vergleich lautet „größer oder gleich“, weil das Token laut RFC ab dem Zeitpunkt exp ungültig ist. Auf dem Server sollten Sie sich auf die Verify-Funktion Ihrer Bibliothek verlassen (jwt.decode mit Schlüssel in PyJWT, jwt.verify in jsonwebtoken, jwtVerify in jose). Sie prüft Signatur und Zeitangaben zusammen.

Sicherheitsgewohnheiten, die sich lohnen

• Behandeln Sie ein gültiges Token wie ein Passwort. Bis es abläuft, kann jeder, der es besitzt, als dieser Nutzer handeln. Nutzen Sie einen lokal arbeitenden Decoder wie unseren, statt Tokens in Chats oder Tickets einzufügen.
• Kurzlebige Access-Tokens, und exp serverseitig verpflichtend machen.
• Ein langes, zufälliges HS256-Secret. PyJWT warnte, unser 20-Byte-Demo-Schlüssel liege „below the minimum recommended length of 32 bytes for SHA256“. Ein 64-stelliges Secret aus dem Passwort-Generator erfüllt diese Grenze mühelos. Unser Leitfaden zum Erstellen eines sicheren Passworts erklärt, warum die Länge zählt.
• Nichts Geheimes in den Payload. Er ist nur kodiert, und jeder kann ihn mit einem Base64-Decoder lesen. Lässt sich ein dekodierter Payload nicht als JSON lesen, prüfen Sie ihn mit dem JSON-Validator und lesen Sie, wie man ungültiges JSON repariert.

Auch Zertifikate laufen ab. Kommt die Fehlermeldung „abgelaufen“ von HTTPS statt von einem Token, hilft Ablaufdatum eines SSL-Zertifikats prüfen.

Jetzt Ihr Token prüfen

Fügen Sie es in den kostenlosen JWT-Decoder ein. Er ist kostenlos und braucht kein Konto. Das Token bleibt in Ihrem Browser, und Sie sehen den Status, alle Zeitangaben in Ihrer Zeitzone und in UTC sowie Warnungen zu den Fallstricken oben.

Häufig gestellte Fragen

Wie finde ich heraus, wann mein JWT abläuft?

Dekodieren Sie den Payload und lesen Sie den exp-Claim, der die Sekunden seit dem 1. Januar 1970 UTC zählt. Mit 1000 multipliziert ergibt er ein JavaScript-Datum. Oder Sie fügen das Token in den JWT-Decoder von My Botsy ein, der exp in Ihrer Zeitzone und in UTC anzeigt.

Läuft ein JWT genau zum exp-Zeitpunkt ab?

Ja. Laut RFC 7519 darf das Token ab dem exp-Zeitpunkt, einschließlich, nicht mehr akzeptiert werden, also vergleichen Sie mit größer oder gleich. Viele Server geben wegen Uhrenabweichungen ein paar Sekunden Toleranz.

Warum lehnt der Server ein Token ab, das laut Decoder nicht abgelaufen ist?

Typische Ursachen sind eine abweichende Serveruhr, ein nbf in der Zukunft, eine falsche Zielgruppe oder ein falscher Aussteller, oder eine ungültige Signatur. Der Decoder liest nur die Zeitangaben. Der Server prüft zusätzlich die Signatur und die übrigen Claims.

Was ist, wenn ein JWT kein exp hat?

Die meisten Bibliotheken akzeptieren es, und das Token läuft nie von selbst ab. Machen Sie exp serverseitig zur Pflicht, zum Beispiel mit der Option require in PyJWT, und halten Sie Access-Tokens kurzlebig.

Ist es sicher, ein JWT in einen Online-Decoder einzufügen?

Nur, wenn der Decoder lokal arbeitet. Der Decoder von My Botsy dekodiert in Ihrem Browser, und das Token wird nie an unseren Server gesendet. Behandeln Sie ein gültiges Token trotzdem wie ein Passwort, und nutzen Sie für Beispiele abgelaufene oder Testtokens.

Ist der JWT-Decoder von My Botsy kostenlos?

Ja. Er ist kostenlos, braucht kein Konto und läuft in Ihrem Browser. Gäste haben 5 Nutzungen pro Tag, und ein kostenloses Konto hebt dieses Limit auf.