Guide
JWT exp, iat, and nbf time claims explained
Convert and distinguish the exp, iat, and nbf claims in a JWT without confusing decoding with security validation.
by Tools in a Tab · Published on · Reviewed on
Short answer
The exp, iat, and nbf claims describe different moments in a JWT. All
three use NumericDate: seconds from 1970-01-01T00:00:00Z, ignoring leap
seconds. They are not milliseconds.
| Claim | Meaning | Main rule |
|---|---|---|
iat |
issued at | When the token was issued |
nbf |
not before | Do not accept before this instant |
exp |
expiration time | Do not accept at or after this instant |
Example
{
"iat": 1767225600,
"nbf": 1767225600,
"exp": 1767229200
}exp - iat = 3600, so the stated window lasts one hour. Paste each number into
the timestamp converter with seconds and
UTC selected to inspect the dates.
Decoding is not validation
The JWT decoder reads a header and payload locally,
but it does not verify the signature. Anyone can construct a string with a
future exp. An application may trust claims only after validating the
signature or MAC, algorithm, issuer, audience, and its own policy.
Clock skew
RFC 7519 allows a
small leeway for slightly unsynchronized clocks when evaluating exp and
nbf. Keep it deliberate and small: a large allowance effectively extends the
token’s accepted lifetime.
Common mistakes
- Treating
expas a duration rather than an absolute instant. - Multiplying a
NumericDateby1000and storing it back in the JWT. - Declaring a token valid merely because
expis in the future. - Ignoring
nbfor confusing it withiat. - Displaying local time without identifying the zone.
- Logging or pasting real tokens that contain sensitive claims.
For debugging, use a test token, decode it locally, convert all three claims to UTC, and compare their order. The final security decision belongs in the system’s verifier, not in a reading tool.