Contact

Tools  /  Security  /  JWT Expiration Checker

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.

Frequently asked questions

Does this tool verify a JWT signature?
No -- it only reads and reasons about the exp/nbf/iat timing claims. To verify a signature against a secret or public key, use this site's JWT Decoder & Generator. To audit header/payload structure and security red flags, use the JWT Structure Viewer.
What is clock-skew leeway and why would I change it?
A small tolerance (commonly 5-60 seconds in real JWT libraries) applied to timing checks to absorb minor differences between two servers' clocks. Increasing the leeway here shows you exactly how much slack would change a borderline token's pass/fail status -- useful for understanding why a token that "should" be valid is being rejected by a strict verifier, or vice versa.
What is nbf and when is it used?
"Not before" -- the token isn't valid until this time, even though it already exists. Useful for pre-issuing a token that should only start working at a scheduled moment, like a time-delayed access grant.
What is a reasonable access token lifetime?
Commonly 5-15 minutes for access tokens that guard sensitive actions, balanced against a longer-lived refresh token (days to weeks) that lets a user stay signed in without re-entering credentials constantly. See the Lifetime Guidance tab for the full breakdown by token type.
What happens if a token has no exp claim?
It never expires by the token format's own logic -- expiration is enforced entirely by whatever checks a verifier chooses to run. A missing exp might be intentional (a long-lived API key) or a configuration mistake; this tool flags it either way without assuming which.
Can I check several tokens at once?
Yes -- the Batch Check tab accepts one token per line and reports each one's expiration status and time remaining or elapsed.
Is anything I paste here sent anywhere?
No. Every decode and timing calculation runs entirely in your browser -- this tool has no server component.
Theme Accent