How a JWT expires
The exp claim holds the moment after which the token must be rejected. It is a Unix timestamp in seconds. The nbf claim is the earliest moment the token is valid, and iat is when it was issued. This checker compares those three values with the current time.
What you see
- A clear status: valid, expired, not valid yet, or no expiry.
- A live countdown to expiry or the time since expiry.
- A bar showing how much of the token lifetime is used.
- The date of each time claim in UTC.
Clock skew and leeway
Servers rarely agree on the time to the second. Many libraries accept a small leeway, often 30 to 120 seconds, so a token is not rejected because of a slow clock. Enter a leeway to see how it changes the result.
Check at another time
Pick a date and time to see whether the token will be valid then, or was valid then. This helps when you debug a failure that happened in the past.
Why a fresh token says expired
- The exp is written in milliseconds instead of seconds.
- The clock of the issuer or of the receiver is wrong.
- The lifetime was set too short, or in the wrong unit.
Related tools
Read the whole token with the JWT decoder, or set times when you create one with the claims builder and the create token form. The JWT guide covers lifetimes and refresh tokens.