Expiration Checker

Expiration Checker

JWT expiration checker online. Check if your JWT is expired, see time remaining, and view exp/iat/nbf timestamps in human-readable format with timezone support.

Time Claims Explained

  • • exp (expiration) — Token is invalid after this time
  • • iat (issued at) — When the token was created
  • • nbf (not before) — Token is invalid before this time
  • • All times are Unix timestamps (seconds since Jan 1, 1970)

Features

  • Tells you at a glance whether a token is expired or still valid
  • Shows the time remaining until expiry (or how long ago it lapsed)
  • Converts exp, iat, and nbf into readable dates in your timezone
  • Explains the not-before window so early tokens make sense
  • Processes the token locally without sending it anywhere

Common Use Cases

  • Diagnosing "401 Unauthorized" errors caused by expired tokens
  • Confirming how long a session token is meant to last
  • Checking that a freshly issued token is not rejected by an nbf in the future
  • Comparing issued-at and expiry to understand a provider’s token lifetime

How JWT expiry actually works

Time in a JWT is stored as Unix timestamps — the number of seconds since January 1, 1970 (UTC). Three claims control timing: iat (when the token was issued), exp (when it stops being valid), and nbf (a time before which it must not be accepted).

A token is considered active when the current time is at or after nbf and strictly before exp. Most servers also allow a small amount of "clock skew" — usually a minute or two — so tokens are not rejected just because two machines' clocks disagree slightly.

Expiry is enforced by whoever verifies the token, not by the token itself. This checker reads the timestamps for you, but the real decision still happens server-side.

Examples

Valid - exp set well into the future (still valid)
{ "iat": 1516239022, "exp": 1916239022 }
Invalid - exp already in the past (expired)
{ "iat": 1516239022, "exp": 1516242622 }

Frequently Asked Questions

My token decodes fine but the API rejects it — why?
A token can be perfectly well-formed and still be expired. Check the exp claim here; if the expiry time has passed, the server is right to reject it and you need a fresh token.
What is clock skew and why does it matter?
Servers and clients rarely have perfectly synced clocks, so verifiers usually permit a small leeway (often 60 seconds) around exp and nbf to avoid rejecting otherwise-valid tokens.
Is exp required?
It is optional in the spec, but strongly recommended. A token with no exp never expires on its own, which is a security risk if it is ever leaked.

Related Tools

JWT Decoder

Inspect the full token structure

Try it

JWT Claims Viewer

Understand every claim in the payload

Try it

JWT Size Analyzer

Check how large a token has grown

Try it