JWT exp, nbf and iat claims explained with real timestamps

How this is calculated

RFC 7519 is precise about the comparisons. For exp, the current time must be before the expiration time, so a token is already invalid at the exact second exp names. For nbf, the current time must be after or equal to the not before time, so a token becomes valid at the exact second nbf names. Both checks may allow a small leeway for clock drift, which the RFC says should usually be no more than a few minutes. iat has no pass or fail rule in the RFC. Libraries use it for a maximum age setting, and a decoder can use it to show a token's planned lifetime, the gap from iat to exp. All three are optional. A token without exp never expires on its own, which is why most identity providers always add it, and why RFC 8725 tells verifiers to think hard before accepting a token without one. The values must be numbers. A quoted "1767226500" is a string, and strict libraries reject it. A 13-digit value is almost always milliseconds from JavaScript's Date.now(), which makes a library read a date thousands of years away. The JWT Decoder shows each time claim as a date in your time zone or UTC, with how long ago or from now it is, and it flags strings and millisecond values.

Verdict

Read exp first: it answers most "why was my request rejected" questions on its own. Then check nbf if a brand new token fails, and compare iat with your server clock if tokens look like they come from the future. Write all three in whole seconds, and use a library's leeway setting rather than editing exp to work around clock drift.