Identity and security
Understanding JWT exp, nbf and iat time claims
Convert JWT NumericDate values correctly and diagnose expiry, not-before and issued-at failures without confusing time zones or clock skew.
In brief
JWT time claims count seconds from the Unix epoch in UTC. Their security meaning still depends on verifier policy, clock quality and an intentionally bounded skew allowance.
NumericDate values are seconds, not milliseconds
JWT defines NumericDate as the number of seconds from 1970-01-01T00:00:00Z, ignoring leap seconds in the same general way as POSIX time. JavaScript date APIs commonly accept milliseconds, so passing a JWT value directly can produce a date in January 1970. Multiply seconds by 1,000 only at the boundary of an API that explicitly expects milliseconds.
Display the result in UTC first. A local-time rendering can be useful for an operator, but it should be accompanied by the UTC value so engineers in different regions compare the same instant.
Seconds and milliseconds
JWT NumericDate: 1784203200 seconds
JavaScript input: 1784203200000 milliseconds
UTC: 2026-07-16T12:00:00ZEach registered claim answers a different question
The exp claim identifies the time on or after which a token must not be accepted. The nbf claim identifies the time before which it must not be accepted. The iat claim records when it was issued and can support age or replay policies, but the base JWT specification does not make it an automatic validity window by itself.
A verifier may allow a small amount of clock skew for distributed systems, but that allowance should be deliberate and bounded. A large skew weakens expiry and not-before controls. The token's dates should also make sense together: for example, an expiry earlier than issuance is a strong sign of bad configuration or malformed test data.
Diagnose clock-related failures with evidence
Capture the verifier's UTC time, the raw NumericDate values, their UTC conversions and the configured skew allowance. Compare the application host with its approved time source. Container, virtual-machine and identity-provider clocks can drift or inherit incorrect configuration even when an engineer's laptop appears correct.
Avoid changing system time or expanding skew merely to make a token pass. First establish which clock is wrong, correct the underlying synchronization issue and retest with a newly issued non-production token.
- Confirm whether the source uses seconds or milliseconds.
- Compare in UTC before applying a local timezone.
- Record the verifier's actual time and configured skew.
- Issue a fresh test token after correcting time synchronization.
Time checks do not replace signature and audience checks
An attacker can write any exp, nbf or iat value into an unsigned or improperly verified payload. Convert time claims for diagnosis, but treat them as untrusted until the token passes the complete verification policy.
When documenting a failure, state whether the values were only decoded or were evaluated by the actual receiving service. This avoids turning a convenient timestamp conversion into an unsupported security conclusion.
Primary references
These sources support the standards and security claims in this guide. Links open on the publisher’s site.
Continue learning
JWT decoding versus verification: what the result actually proves
Learn why readable JWT claims are not trustworthy until the signature, algorithm, issuer, audience and time rules are verified in the correct security context.
Read guideUnix timestamps for incident response and log correlation
Convert epoch values reliably, distinguish seconds from milliseconds and correlate events across UTC, local time and systems with clock drift.
Read guide