JWT Expiration Calculator
Turn a JWT exp timestamp into a readable UTC date, or build the exp value for a token lifetime from its iat claim.
What it does
A JSON Web Token carries its own expiry inside the payload, in a claim called exp. The value is a NumericDate, defined by RFC 7519 as seconds counted from 1970-01-01T00:00:00 UTC, the same clock Unix systems use.
Many bugs trace back to one mix-up: JavaScript timestamps count milliseconds, while exp counts seconds. Multiply by 1000 before building a Date, or a one-hour token appears to live for decades.
The validator's rule is simple: once the current time reaches exp, the token is expired, full stop. There is no grace built into the spec, though servers often allow a small clock-skew window, and RFC 8725 warns against stretching that leeway.
In the other direction, exp is built by taking the issued-at time, iat, and adding the intended lifetime in seconds. A token issued now that should live for one hour gets exp = now + 3600.
This page converts either way and shows the date in UTC, where the arithmetic is exact. Whether the token is expired reads against the clock of the machine viewing the page; tokens are judged by the server's clock, not the browser's.
How to use
- Choose the direction: decode an existing exp, or build a new one.
- To decode, paste the exp number from the token payload.
- To build, enter iat and the lifetime, then pick seconds, minutes, hours, or days.
- Read the UTC date and the exact exp seconds.
- Check the status line, remembering it reflects this machine's clock.
- Remember that decoding does not verify the token; only the server's signature check does that.
Formula
- exp
- Expiration time claim, in whole seconds since the epoch.
- iat
- Issued-at claim, the token start time in the same seconds.
- NumericDate
- RFC 7519's seconds-since-1970 format, ignoring leap seconds.
RFC 7519 defines exp as a NumericDate and says the token must not be accepted once the current time is on or after exp. RFC 8725 adds the production advice: keep lifetimes short, validate exp strictly, allow at most a small documented clock skew, and pair long-lived sessions with refresh tokens rather than stretching exp.
Worked example
Example: decoding exp 1767225600
The default timestamp decodes to New Year's Day 2026 (defaults).
- Divide by 86,400: 1767225600 / 86400 = 20454 days after the epoch.
- 20454 days after 1970-01-01 lands on 2026-01-01.
- Remainder zero means the exact midnight, 00:00:00 UTC.
- So the token expired at Thu Jan 01 2026 00:00:00 UTC.
- Any clock past that instant reads the token as expired; the tool confirms it.
Reference table
| Lifetime | Seconds to add to iat |
|---|---|
| 15 minutes | 900 |
| 1 hour | 3,600 |
| 1 day | 86,400 |
| 7 days | 604,800 |
| 30 days | 2,592,000 |
Limits
- Only the exp claim is handled; signature, issuer, and audience checks are separate.
- The tool does not decode a full token, so it never sees who issued it or whom it is for.
- UTC dates are shown exactly; local time zones and leap seconds are out of scope.
- A status reading of valid or expired uses this machine's clock, not the server's.
Common mistakes
- Treating exp as milliseconds; JavaScript's Date.now() gives milliseconds, exp counts seconds.
- Believing a token is safe because exp is far away, while ignoring signature and audience checks.
- Setting long expiries instead of using refresh tokens, which widens the replay window if a token leaks.
- Assuming exp is secret; it is only base64url encoded, so anyone can read it.
- Forgetting that nbf can keep a token unusable before a start time even when exp looks fine.
Try it yourself
Quick checks. Answers sit tucked under each question.
exp 1609459200?
Fri Jan 01 2021 00:00:00 UTC, long expired.
iat 1767225600 plus 1 hour?
exp 1767229200, or Thu Jan 01 2026 01:00:00 UTC.
exp 2000000000?
Wed May 18 2033 03:33:20 UTC.
Questions
Where do I find exp in a token?
In the payload, the middle of the three base64url segments. Decode that segment as JSON and read the exp number; it is not encrypted, just encoded.
Why does my token show expired but the app still accepts it?
Servers may allow a small clock-skew window, or the app may not validate exp at all. RFC 8725 treats missing strict validation as a bug worth fixing.
What are nbf and iat?
iat is when the token was issued; nbf is the earliest time it may be used. Both are NumericDates in the same seconds format as exp.
Does a valid exp stop token replay?
No. A captured token works until exp, so short lifetimes, TLS, and revocation or refresh design are what limit replay damage.
Should exp be an absolute time or a duration?
Always an absolute NumericDate. The payload is fixed at signing time, so a duration would be meaningless to a validator.
How much clock skew should I allow?
Keep it small and documented, a minute or two at most. Every extra second is a second a stolen token still works.
Sources
- RFC 7519: JSON Web Token, exp and NumericDate definitions
- RFC 8725: JSON Web Token Best Current Practices