JWT Expiry Checker

Q: Can I check JWT expiry without the secret key?

Yes — the exp claim is in the payload, which is Base64-decoded without any key. Anyone can read JWT claims without the signing key. The signing key is only needed to verify that the claims haven't been tampered with. For debugging and development, reading the exp claim without verification is fine. In production, always verify the signature before acting on any claim — an attacker can craft a token with any exp value they want.

Q: Why is my JWT expiring earlier than expected?

The most common cause is a timezone mismatch. JWT exp is always UTC Unix seconds — if the issuing server's clock is set to local time without UTC conversion, or if you're comparing to local time instead of UTC, the expiry appears off. Check: new Date(exp * 1000).toISOString() gives the exact UTC expiry time. Another cause is a shorter-than-expected exp value set by the auth provider — many services issue short-lived tokens (15 minutes) by design and expect clients to refresh them.

Check if a JWT token is expired. Paste any JWT to instantly see the expiration time (exp claim), issued-at time (iat), and how much time remains — or how long ago it expired.

Is Your JWT Token Expired?

Paste a JWT and instantly see whether it's valid, expired, or not-yet-valid — along with the exact expiry timestamp, time remaining, and all decoded claims. No signature verification required to check expiry.

Expiry status: Valid, expired, or not-yet-valid with exact time remaining
exp and iat claims: Human-readable dates for issue time and expiration
All claims decoded: Full header and payload displayed
Private: Token decoded in your browser — never sent to a server

Check JWT Expiry →

JWT Time Claims Explained

exp (Expiration Time): Unix timestamp after which the token must not be accepted. Required by most auth systems — if missing, the token never expires
iat (Issued At): Unix timestamp when the token was created — useful for calculating token age and detecting stale tokens even without a short expiry
nbf (Not Before): Unix timestamp before which the token must not be accepted — used for tokens issued in advance that shouldn't be used immediately
Clock skew: Servers typically allow 30–60 seconds of clock skew when validating exp — a token "expired" by a few seconds may still be accepted
All timestamps are UTC: JWT time claims are always Unix seconds since the UTC epoch — convert to local time for display

Checking JWT Expiry in Code

JavaScript: JSON.parse(atob(token.split('.')[1])).exp * 1000 > Date.now() — true if not expired
Python (PyJWT): jwt.decode(token, options={"verify_signature": False}) returns claims including exp as a Unix timestamp
Node.js (jsonwebtoken): jwt.decode(token) returns the payload without verification — check payload.exp > Math.floor(Date.now()/1000)
Warning: Decoding without verification only tells you what the token claims — always verify the signature in production before trusting any claims

Frequently Asked Questions

Can I check JWT expiry without the secret key?

Yes — the exp claim is in the payload, which is Base64-decoded without any key. Anyone can read JWT claims without the signing key. The signing key is only needed to verify that the claims haven't been tampered with. For debugging and development, reading the exp claim without verification is fine. In production, always verify the signature before acting on any claim — an attacker can craft a token with any exp value they want.

Why is my JWT expiring earlier than expected?

The most common cause is a timezone mismatch. JWT exp is always UTC Unix seconds — if the issuing server's clock is set to local time without UTC conversion, or if you're comparing to local time instead of UTC, the expiry appears off. Check: new Date(exp * 1000).toISOString() gives the exact UTC expiry time. Another cause is a shorter-than-expected exp value set by the auth provider — many services issue short-lived tokens (15 minutes) by design and expect clients to refresh them.

What should I do when a JWT is expired?

The standard pattern is to use a refresh token: when the access token (short-lived JWT, typically 15 min–1 hour) expires, the client sends the refresh token (long-lived, typically 7–30 days) to the auth server's /token/refresh endpoint to get a new access token without requiring the user to log in again. If the refresh token is also expired, the user must re-authenticate. Never extend a JWT's expiry by modifying the payload — the signature will no longer be valid.