JWT Expiration Checker
A live countdown/elapsed ticker for a JWT's exp/nbf/iat timing, an adjustable clock-skew leeway, batch expiry-checking for multiple tokens at once, and real token-lifetime conventions -- timing only, never verification.
What this tool does
Decodes a JWT's exp, nbf, and
iat claims specifically, with a live countdown or
elapsed-time ticker, a visual timeline, an adjustable
clock-skew leeway, and batch checking for a whole list of
tokens. This is a focused, timing-only companion to this site's
general JWT Decoder & Generator
and the structure-focused
JWT Structure Viewer --
here specifically for "is this token's clock window valid right
now," never for verifying a signature or auditing header
fields.
The three timing claims
iat (issued at) records when a token was
created. nbf (not before) says the token isn't
valid until that time -- useful for tokens issued in advance of
when they should start working. exp (expiration)
is the hard cutoff after which the token must be rejected,
regardless of anything else being valid. All three are Unix
timestamps in seconds, per RFC 7519, and none of them are
enforced automatically by the JWT format itself -- a verifier
has to actually check them, which is exactly what makes a
token with no exp claim at all a real (if
sometimes intentional) risk.
Clock skew: why real verifiers add a small leeway
Two servers' clocks are never perfectly in sync. A token
that expired one second ago on the issuing server's clock might
still look "not yet valid" or "already expired" on a verifying
server's clock that's running a few seconds fast or slow.
Production JWT libraries account for this with a small
leeway -- commonly somewhere in the 5-60
second range, with values under 30 seconds the most common
default -- applied to exp, nbf, and
sometimes iat checks. It should cover minor drift
between NTP-synced clocks, never substitute for actually
keeping clocks in sync, and should never stretch into minutes --
a multi-minute leeway meaningfully weakens the real security
value of an expiration check. The leeway control on this page
lets you see exactly how a given tolerance changes a borderline
token's status.
Realistic token lifetimes
There's no single correct expiration window -- it depends on what the token protects and how it's used. Short-lived access tokens (commonly 5-15 minutes) limit how long a stolen token stays useful; longer-lived refresh tokens (days to weeks) trade that off against how often a user has to fully re-authenticate; long-lived API keys accept more risk in exchange for not needing a refresh flow at all. The Lifetime Guidance tab lays out the common conventions by token type.
Batch checking
Paste a list of tokens, one per line, and see every one's
exp status at a glance -- useful for auditing a set
of tokens pulled from logs, a test suite, or a set of API keys
issued to different clients.
Privacy
Everything runs entirely in your browser. Nothing you paste here is sent anywhere.