When a token stops working.
Read a JWT's exp, iat and nbf claims as dates in your browser, see why a token is refused as expired or not yet valid, and what clock skew does to it.
By Suraj Kumar4 min read
A request that worked a minute ago now fails with token expired, or a token that was just issued is refused as not valid yet. Both come down to three numbers in the token and two clocks that read them.
Three numbers, counted in seconds.
RFC 7519 defines three time claims: exp, the time after which the token must not be accepted; nbf, the time before which it must not be accepted; and iat, when it was issued. Each is a NumericDate: seconds since 1 January 1970 in UTC, not milliseconds. 1767225600 is 1 January 2026 at midnight UTC.
A common slip is to compare exp with JavaScript's Date.now(), which counts milliseconds. Divide by 1,000 first, or every token looks long expired. Made the other way, a token whose exp was written in milliseconds will not expire for thousands of years.
{
"sub": "123",
"iat": 1767225600, 1 January 2026, 00:00 UTC
"nbf": 1767225600,
"exp": 1767229200 1 January 2026, 01:00 UTC
}Read the times as dates.
Paste the token into the JWT decoder. Each claim is said in words with the standard that defines it, and exp, nbf and iat are shown as dates in UTC with how long ago or ahead they are; the expiry counts down while you look.
Warnings say what the decoder finds: that the token has expired and when, that it may not be used yet, that it has no expiry at all (so a stolen copy works for ever), that it says it was issued in the future (a clock is wrong somewhere), or that it lasts more than 30 days from when it was issued.
Clock skew, and why a fresh token can fail.
The issuer and the service each read their own clock. If the service's clock runs ahead, a token can look expired early; if it runs behind, a new token can look not valid yet. RFC 7519 lets a service allow a small leeway, usually no more than a few minutes, for exactly this, and most JWT libraries have a setting for it.
A token refused within seconds of being issued usually points at a clock, not at the token. Compare the server's time with UTC before changing anything else.
What to do about an expired token.
An expired token cannot be mended: exp is covered by the signature, so changing it breaks the signature. The client needs a new token, usually through a refresh token or by signing in again.
If tokens expire sooner than you expect, compare iat and exp: the gap between them is the lifetime the issuer chose. If they are refused while still in date, check nbf and the clocks.
In date is not the same as genuine.
A token whose dates are fine can still be forged. RFC 8725 asks services to check the signature with the algorithm they expect, and the issuer and audience, as well as the times. The decoder's Verify checks the signature with your key on your device; reading the dates alone checks nothing.
Further reading
Topics: jwt expired · jwt exp claim · jwt iat nbf · jwt expiration time · numericdate · jwt clock skew · convert jwt exp to date · token expired error
A little less theory. A little more doing.
Try it on your own terms, with a free browser tool.
Try the tool