When Does a JWT Expire? The exp Claim Explained

A JWT expires at the exact second written in its exp claim — a Unix timestamp baked into the token when it was issued. Not 'about an hour,' not 'when you log out': a specific moment, stamped on and unchangeable. Once you can find and read that stamp, the mystery of the surprise 401 mostly disappears. Here's how to do it.

The use-by date analogy

Think of exp like the use-by date printed on a carton of milk. The date is stamped right on the product, anyone can read it, and it's the item's own claim about itself. Nobody re-checks the milk each morning — they trust the stamp and toss it once the date passes. A JWT works the same way: the expiry travels inside the token, it's plainly readable, and servers simply trust it until the clock passes it.

Step 1: find the exp claim

A JWT has three dot-separated parts; the middle one is the payload. Decode it — locally, with the JWT Decoder — and look for exp. You'll see something like:

{
  "sub": "1234567890",
  "iat": 1752796800,
  "exp": 1752800400
}

That's the readable payload of any token — which, as our guide on what a JWT is and how to decode it explains, is only Base64url-encoded, not secret.

Step 2: read the timestamp

exp is a Unix timestamp — the number of seconds since January 1, 1970 UTC. 1752800400 isn't a random number; it's a specific date and time. Two ways to translate it:

• Multiply by 1000 and feed it to a date function (new Date(1752800400 * 1000) in JavaScript).
• Skip the math and paste the whole token into the JWT Expiration Checker, which tells you plainly whether it's expired and how long it has left.

Step 3: know the other time claims

exp has two siblings you'll meet:

• iat (issued at) — when the token was created. exp minus iat is the token's total lifetime.
• nbf (not before) — a token can be issued now but only become valid later; before nbf, it's rejected too.

All three are Unix timestamps, read exactly the same way.

Why a token sometimes expires 'early' or 'late'

If a token dies a bit before or after you expect, the usual culprit is clock skew. exp is compared against the verifying server's clock, and two machines are never perfectly in sync. A server whose clock runs 30 seconds fast will reject a token 30 seconds early. The standard remedy is a small leeway (a few seconds to a minute) that libraries allow when checking exp — not a change to the token itself.

Step 4: what to do when it's expired

You don't extend a JWT — its signature covers the exp value, so editing the expiry breaks the token. Instead:

1. Re-authenticate to get a freshly issued token, or
2. Use a refresh token — a longer-lived credential whose only job is to request new short-lived access tokens without making the user log in again.

This is why access tokens are usually short-lived and often arrive as a bearer token in the Authorization header — you can pull the token out of that header with the Bearer Token Parser. Short lifetimes limit the damage if one leaks, and refresh tokens keep the experience smooth.

The takeaway

A JWT's expiry is never a guess — it's the exp timestamp stamped inside the token, read against the server's clock, like a use-by date on a carton. Decode the token to find it, translate the Unix timestamp to a real time, allow a little leeway for clock skew, and refresh rather than extend when it lapses. When you just need a quick yes-or-no on a token in front of you, the JWT Expiration Checker answers it in a second.