JWT "Token Expired" Error, Explained
A token can have a perfectly valid signature and still be rejected — expiration is a separate check, and a signature never expires on its own.
What triggers it
JWTs carry an optional exp claim in the payload: a Unix timestamp (seconds since epoch) marking when the token stops being valid. Verification libraries check exp against the current time in addition to verifying the signature — a token signed correctly an hour ago with exp set to 10 minutes ago is a completely valid signature attached to data that says "don't trust me anymore."
{
"sub": "user-123",
"iat": 1753000000,
"exp": 1753003600
}If the current time is past 1753003600, this token is expired — regardless of signature validity.
Why this is separate from signature verification
Signing proves the token wasn't tampered with since it was issued. Expiration is a policy decision baked into the payload at issue time, saying how long that proof should be trusted. Conflating the two is a common source of confusion: "the signature is valid" and "the token is still usable" are different questions, and most JWT libraries report them as distinct failure reasons for exactly this reason.
How to check it
Paste the token into the JWT Decoder — it checks exp against your local clock automatically and reports the exact expiry time alongside whether it's still valid, with an adjustable clock-skew tolerance for tokens issued by a server whose clock is slightly ahead or behind yours.
Fix the lifecycle, not the claim
Do not edit exp or re-sign a token in the client. Obtain a new access token through the issuer's documented refresh or authentication flow. If many fresh tokens appear expired, compare UTC on the issuer, verifier, container host, and client. Keep clocks synchronized and use only a small tolerance for network delay; a large tolerance silently extends every token's lifetime.
Distinguish access-token expiry from refresh-token expiry. The access token should usually be short lived, while the refresh credential has its own rotation and revocation rules. APIs should return a clear authentication error without exposing sensitive verification details, and clients should avoid infinite refresh loops when renewal is denied.
Frequently Asked Questions
Can an expired token have a valid signature?
Yes. Integrity can be valid while the token is outside its permitted time window.
Should I increase clock skew?
Use a small documented tolerance and correct unsynchronized clocks instead.
Can an expired access token be refreshed?
Only through the issuer's refresh flow while the refresh credential is still valid.