JWT Expired: Every Real Cause and How to Fix It

Published 8 Sep 2026 · 8 min read

TokenExpiredError: jwt expired looks like the simplest JWT failure there is — the clock ran out, get a new token. That's true for a lot of cases, but not all of them: the same error text also shows up when the token was never really "expired" in any meaningful sense, and the bug is somewhere else entirely — a comparison that mixes seconds and milliseconds, a verifier's clock that's a few minutes fast, or a refresh call that's been silently failing for hours. This walkthrough covers five real causes, how to tell them apart, and a live, prefilled JWT Verifier example for the ones that live in the token itself.

Quick reference

All five results below were computed against the exact exp/nbf logic JWT Verifier runs client-side, then verified live in the tool before publishing.

1. The token is honestly past its exp

This is the case the error message describes correctly: the token's exp claim is a real Unix timestamp in the past, and the library is doing exactly what it's supposed to do by rejecting it. It's worth starting here anyway, because it's the baseline every other cause in this piece gets compared against — if decoding the token shows an exp that's actually behind "now," there's no bug to chase, just a token that needs replacing.

jwt.verify(token, secret);
// TokenExpiredError: jwt expired at 2026-06-02T00:00:00.000Z
// (thrown correctly — the token's exp really was three months ago)

2. An ultra-short TTL, eaten by real-world latency

Some tokens are deliberately short-lived on purpose — a one-time magic-link login, a step-up-auth confirmation, a single-use download URL — and a 5-to-30-second TTL is a reasonable security choice for that use case. The bug shows up when the token has to survive a trip that takes longer than its TTL allows: an email delivery delay, a slow client-side redirect, a user who alt-tabbed away before clicking. The token was never wrong; the window was just narrower than the real-world path through it.

// Issued with a 5-second TTL for a one-time login link
const token = jwt.sign({ sub: userId, purpose: 'one_time_login' }, secret, { expiresIn: '5s' });
// ...email delivery, DNS, a slow client, a user who didn't click immediately...
jwt.verify(tokenFromEmailLink, secret);
// TokenExpiredError: jwt expired

3. Your own code compares seconds to milliseconds

RFC 7519 defines exp as seconds since the Unix epoch. JavaScript's Date.now() returns milliseconds. A hand-rolled expiration check that skips the unit conversion — if (payload.exp < Date.now()) — compares a roughly-10-digit number against a roughly-13-digit one, so exp reads as "expired" for every token, including ones minted seconds ago with an hour of real lifetime left. This is a bug in the verifying code, not the token, which is exactly why it's worth ruling out separately from cause 1: the fix is a division, not a new token.

// Buggy — exp is seconds, Date.now() is milliseconds
if (payload.exp < Date.now()) throw new Error('expired');
// payload.exp ≈ 1_820_409_308 (10 digits)
// Date.now()  ≈ 1_788_873_308_412 (13 digits)
// The comparison is true immediately, for every token, forever.

// Fixed
if (payload.exp < Math.floor(Date.now() / 1000)) throw new Error('expired');

4. Clock skew between the issuer and the verifier

JWT expiration is only as reliable as the two clocks it depends on agreeing with each other. If the server issuing tokens and the server (or service, or lambda) verifying them disagree by even a minute or two — a VM that never got NTP configured, a container that drifted after a long uptime, a CI runner with a stale clock — a token that was completely valid the instant it was signed can read as already expired the instant it's checked, or the mirror-image problem: a token can read as "not yet valid" if its nbf claim was set relative to the issuer's clock and the verifier's clock is running behind.

// Issued fine at the issuer's clock time
const token = jwt.sign({ sub: userId }, secret, { notBefore: 0, expiresIn: '1h' });

// Verified on a server whose clock is a few minutes behind the issuer's
jwt.verify(token, secret);
// NotBeforeError: jwt not active
// (the nbf the issuer stamped hasn't "arrived" yet on the verifier's clock)

// Mitigate with a tolerance buffer rather than assuming clocks agree exactly
jwt.verify(token, secret, { clockTolerance: 30 }); // seconds

5. A silently failed refresh keeps resending a stale token

Not every "expired" report is really about the token that got sent — sometimes it's about the token that should have been sent and wasn't. A common pattern: a client holds a short-lived access token and a longer-lived refresh token, and refreshes automatically in the background before the access token expires. If that background refresh call fails — a network blip, a refresh token that itself expired, an error swallowed by a bare catch {} with no logging or retry — the client keeps reusing the same now-expired access token on every request, because nothing ever told it the refresh didn't happen.

// The failure mode that hides this bug
async function getValidToken() {
  try {
    return await refreshAccessToken(); // fails — expired refresh token, network error, whatever
  } catch {
    return cachedAccessToken; // silently falls back to the token that's the whole problem
  }
}

This one doesn't have a live "broken token" example, because the token itself is fine in isolation — the same genuinely-expired shape as cause 1, just arrived at via a different, invisible route. The tell is behavioral rather than something you can see by decoding a single token: the user reports being logged out "randomly," but the access token in the failing request is hours old, not seconds, and a fresh login fixes it instantly. Make refresh failures loud — log them, surface a re-auth prompt, don't fall back to a token you already know is stale — so this shows up as an obvious refresh-flow bug instead of a mysterious intermittent "expired" report.

Debugging checklist

1. Decode the token first and read exp (and nbf, if present) as an actual human-readable timestamp, not a raw number. Confirm whether it's genuinely in the past before assuming anything else.
2. If exp is genuinely in the past by seconds rather than hours, check the TTL against the real-world latency the token has to survive, not a local happy-path test.
3. If exp looks completely healthy but your app still rejects it, check your comparison code for a missing /1000 between seconds and milliseconds — this one bug rejects every token, every time.
4. If the failure is inconsistent and clusters right around the expiration boundary, compare the issuing server's clock and the verifying server's clock directly rather than assuming they agree.
5. If the "expired" token turns out to be hours old rather than freshly issued, look at the refresh flow's error handling before looking at the token at all.

← Back to Blog · Next: JWT Signature Verification Failed →