JWT Expiration Checker: Decode and Validate Time Claims

How to use the jwt expiration checker

1. Paste your JWT into the text area above.
2. The tool automatically splits the token and decodes the payload as base64url JSON.
3. Review the extracted exp, iat and nbf timestamps.
4. Check the status row to see if the token is not expired, expired or not yet active.

How JWT time claims work

A JSON Web Token carries three standard time claims defined in RFC 7519. Each value is a Unix timestamp representing seconds since 1 January 1970 UTC.

• exp (Expiration Time): the moment after which the token must be rejected. If the current time is equal to or greater than exp, the token is expired.
• iat (Issued At): when the token was created. It does not affect validity on its own but helps detect tokens that are suspiciously old.
• nbf (Not Before): the earliest moment the token may be accepted. If the current time is less than nbf, the token is not yet valid.

This jwt expiration checker reads those numeric values from the decoded payload and compares them against your local clock to determine the token's status.

Decoding the payload manually

A JWT consists of three base64url-encoded parts separated by dots: header, payload and signature. To inspect the claims yourself, take the middle segment and decode it.

For example, given the payload string eyJleHAiOjE1MTYyNDI2MjJ9:

1. Replace - with + and _ with /.
2. Add = padding until the length is a multiple of four.
3. Base64-decode to get the UTF-8 JSON: {"exp":1516242622}.

The resulting exp value of 1516242622 corresponds to 18 January 2018 at 02:30:22 UTC. Because that date is in the past, the token is expired. The jwt expiration checker performs these steps automatically and also converts the timestamp into a readable date.

Common reference timestamps

When debugging tokens it helps to recognise familiar Unix epoch values. Here is a quick reference table:

If you see an exp claim near zero, the token likely expired decades ago. Values beyond 2000000000 indicate an expiration well into the 2030s.

Why tokens expire and how to handle it

"Not expired" only means the time claims are in range; this tool does not check the signature, so it cannot tell you the token is genuine. Short-lived tokens limit the window an attacker can misuse a stolen credential. A typical access token might have an exp set 15 minutes after iat. When the jwt expiration checker shows "Expired", the client application should request a fresh token using a refresh token flow or re-authenticate the user.

The nbf claim is less common but useful for scheduled access. For instance, a conference badge token might carry an nbf set to the event start time so it cannot be used early. If the status reads "Not yet valid", simply wait until the nbf time passes.

Tokens without an exp claim never expire according to the standard. While convenient during development, issuing tokens without expiration in production is a security risk because a leaked token remains usable indefinitely.

Worked examples