JWT Expiration Checker
The exp claim is a Unix timestamp, which tells you nothing at a glance. Paste the token and this page turns it into a date, a time zone you recognise and a plain sentence.
Sign a token of your own to test an endpoint. Everything is computed in this page.
The key and the finished token stay in your browser; neither is sent anywhere, and neither is carried in a share link.
Verify this token in your own code. The snippet follows the algorithm in the header.
Check When a JSON Web Token Expires
A rejected request is rarely mysterious for long: the first thing worth checking is whether the token was still alive when it arrived. The trouble is that the answer is stored as something like 1790208000, and nobody reads that at a glance. Paste the token and the line above the decoded header says it in words — expired two days ago, expires in fifty-eight minutes, not valid yet — while the claims table gives the full date in your own zone.
Everything is decoded in the page. That matters here because a token is a live credential: anyone holding a valid one can usually act as its subject until the moment this page is telling you about. Nothing you paste is uploaded, logged or kept.
The three claims that carry time
| Claim | Meaning | What a wrong value looks like |
|---|---|---|
exp | The token stops being accepted at this moment | A 401 that appears some fixed time after every login |
nbf | It may not be used before this moment | A brand-new token rejected for the first few seconds |
iat | When it was issued | Used by maximum-age rules, so an old but unexpired token still fails |
All three are seconds since the Unix epoch, not milliseconds — a JWT written by hand with a JavaScript Date.now() lands in the year 58,000 and is accepted by nothing. If you need to convert one of these numbers on its own, the timestamp converter does the same arithmetic in both directions.
Expired, or just out of step?
Two machines rarely agree on the time to the second, so every sensible verifier allows a little leeway — thirty to sixty seconds is typical. That tolerance is why a token can look expired here by a few seconds and still be accepted, and why a token issued by a server whose clock runs fast can be refused as not yet valid for its first moments. If a token fails a long way outside that window, the clock is not the problem.
The other half of the answer is the signature. An expired token can carry a perfectly good signature, and a forged one can carry an exp far in the future; the two questions are independent. This page reports both — verify the signature with the key under the token, and an expired result still says so alongside the valid one.
How long a token should live
Short, because a token cannot be taken back. Once it is signed, anyone holding it is that user until exp passes, so an access token that lives for fifteen minutes limits the damage of a leak in a way that one living for thirty days does not. The usual arrangement pairs a short access token with a long refresh token that is stored server-side and can be revoked — which is exactly the trade the comparison with session cookies goes into.
If you are testing that behaviour rather than diagnosing it, the JWT generator will sign a token that expires in five minutes, or one with no expiry at all, so you can watch how your own code reacts.