JWT Expiration Checker
JWT Expiration Checker decodes the payload, reads exp as Unix seconds, converts it to an ISO time, and labels it Expired or Not expired relative to the current browser clock. It does not verify the signature or any other claim, so a forged token can display a convincing future date. “Not expired” never means valid.
Runs locally — files stay on your deviceDoes “Not expired” mean a JWT can be accepted?
No. Signature, issuer, audience, not-before, token type, key policy, and application rules still require validation.
The exp claim defines a latest acceptance time
exp is a NumericDate measured in seconds since the Unix epoch. A verifier must reject a token at or after that time, subject only to a small configured clock-skew allowance.
How it works
The tool decodes the second segment, parses JSON, multiplies exp by 1000 for a JavaScript Date, and compares it with Date.now. Tokens without exp receive a specific message.
Key concepts
exp is seconds, not milliseconds
Using the wrong unit shifts the displayed time drastically.
Unverified claims are attacker-controlled
The page never proves who created the token.
When to use it
- Read a synthetic token's stated expiration.
- Convert exp seconds to ISO UTC.
- Debug seconds-versus-milliseconds mistakes.
When not to use it
- Do not use the result as token validation.
- Do not assume the browser clock is authoritative.
- Do not ignore nbf, issuer, audience, signature, or revocation.
Worked examples
Past exp
- Input
Payload exp earlier than now- Expected output
Expired
The browser-clock comparison is negative.
Future exp
- Input
Payload exp later than now- Expected output
Not expired
Other validation is still absent.
Missing claim
- Input
Payload without exp- Expected output
No exp claim present
The checker does not invent a lifetime.
Common mistakes
Accepting Not expired as valid
Only one unverified claim was compared. Correction: Run full library-based validation.
Providing milliseconds
JWT NumericDate uses seconds. Correction: Convert to Unix seconds.
Ignoring clock skew policy
Distributed clocks can differ slightly. Correction: Use a small explicit verifier allowance.
Best practices
- Verify signature before trusting claims.
- Use short-lived tokens and server-controlled clocks.
- Validate the complete application claim profile.
Related operations and differences
Basic Auth Header Generator
Choose Basic Auth Header Generator when you need to generate a Basic Authorization header locally.; use JWT Expiration Checker specifically for jwt expiration.
HMAC Generator
Choose HMAC Generator when you need to create an HMAC using the browser Web Crypto API.; use JWT Expiration Checker specifically for jwt expiration.
JWT Header Viewer
Choose JWT Header Viewer when you need to decode a JWT header without verifying its signature.; use JWT Expiration Checker specifically for jwt expiration.
JWT Payload Viewer
Choose JWT Payload Viewer when you need to decode a JWT payload without verifying its signature.; use JWT Expiration Checker specifically for jwt expiration.
Passphrase Generator
Choose Passphrase Generator when you need to generate a local random multi-word passphrase.; use JWT Expiration Checker specifically for jwt expiration.
Password Entropy Calculator
Choose Password Entropy Calculator when you need to calculate estimated entropy from an assumed character pool.; use JWT Expiration Checker specifically for jwt expiration.
Limitations and privacy
- No signature or claim validation beyond reading exp.
- Uses the device clock.
- No configured skew, revocation, issuer, audience, nbf, or token-type checks.
The entered value is processed locally in this browser. Avoid using an untrusted device for real credentials or secrets.
Frequently asked questions
What unit is exp?
Unix seconds.
Does Not expired mean valid?
No.
What if exp is missing?
The tool reports that no exp claim is present.
Is the signature verified?
No.