JWT Expiry Calculator

Calculate JWT expiration timestamps from durations and convert exp/iat/nbf claims to human-readable dates.

Tested tool guide Tested browser tools Checked August 16, 2026

What JWT Expiry Calculator does and how it behaves

JWT timing claims are numbers rather than formatted dates. This calculator translates exp, iat, and nbf NumericDate values into human-readable instants, and it calculates an exp timestamp from a token lifetime duration. It is useful when checking whether a payload's timing matches the intended issue, activation, and expiration schedule. The frequent mistake is supplying a JavaScript-style timestamp in milliseconds. JWT NumericDate uses seconds from the Unix epoch, so treating a 13-digit millisecond value as a claim moves the interpreted date far beyond the intended instant.

How the result is produced

Claim interpretation

Under RFC 7519, exp, nbf, and iat use NumericDate: seconds since 1970-01-01T00:00:00Z, with leap seconds ignored. The calculator maps each value to its corresponding date and time. exp marks the expiration cutoff, nbf marks the not-before boundary, and iat records issuance. This conversion changes representation; it does not prove that the claims are truthful.

Duration arithmetic

For a duration calculation, the expiration is the reference instant plus the entered interval. If iat is used as that reference, exp minus iat is the nominal lifetime in seconds. The numeric expiration and formatted date represent the same instant, even if a time-zone offset changes the clock notation. This arithmetic does not determine whether a verifier will accept the token.

Good uses

Convert an exp claim copied from a decoded access token into a calendar time while investigating an authentication failure or an unexpectedly early logout.
Calculate the exp value corresponding to a planned token lifetime, then compare it with iat to confirm that the intended number of seconds was applied.
Compare iat, nbf, and exp from one payload to find an implausible sequence, such as a token becoming usable only after its expiration cutoff.

Limits and checks

Confirm the units before converting. JWT NumericDate uses seconds, while Date.now() and many browser logs expose milliseconds. A value can be numeric yet be off by a factor of 1,000 and produce a distant date.
Treat every formatted date together with its time zone. UTC and local representations can show different hours or calendar dates while identifying the same instant. Compare the epoch value or normalized UTC time across systems.
A calculated future exp does not validate a JWT. Signature, issuer, audience, nbf, required claims, revocation, and verifier policy can independently cause rejection. Clock-tolerance settings can also affect behavior near timing boundaries.

Common questions

Can exp tell me how long the token was intended to live?

Not from exp alone. exp identifies the cutoff instant. If a trustworthy iat is also present, subtracting iat from exp gives the nominal lifetime in seconds. That still describes the issuer's timestamps, not necessarily the full period during which every verifier accepts the token, because nbf, clock tolerance, revocation, and other validation rules can narrow acceptance.

What happens at the exact exp timestamp?

Under RFC 7519, a token must not be accepted on or after its exp time, so the exact expiration instant is outside the normal validity interval. A verifier may allow configured leeway for clock differences, so behavior close to the boundary can vary. The calculator shows the timing result; it cannot determine the verifier's clock or policy.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.