JWT Expiration Time: How to Check the exp Claim

When a JWT suddenly stops working, the first field to check is usually exp.

In RFC 7519, the exp claim identifies the expiration time on or after which the JWT must not be accepted for processing. The value is a NumericDate, usually shown as seconds since the Unix epoch.

How to Read exp

A decoded payload might look like this:

{
  "sub": "123",
  "iat": 1760000000,
  "exp": 1760003600
}

To understand it:

1. Decode the JWT payload.
2. Find exp.
3. Convert the timestamp to UTC or local time.
4. Compare it with the current time.

If the current time is equal to or after exp, the token is expired.

Seconds vs Milliseconds

JWT NumericDate values are normally seconds. JavaScript Date.now() returns milliseconds, so developers often multiply or divide by 1000 in the wrong place.

Common checks:

const isExpired = Date.now() >= payload.exp * 1000;

Do Not Trust a Decoded Token Alone

Decoding a JWT only shows the header and payload. It does not prove the signature is valid. Use a decoder for debugging, but let your backend or auth library verify signatures and expiration.

Quick Answer

Decode the JWT, read the exp claim, treat it as seconds since the Unix epoch, convert it to a readable date, and compare it with the current time. An expired JWT should not be accepted, even if the payload still looks valid.

What to Double-Check

| Check | Why it matters | | ----------------- | -------------------------------------------------------------------------------------------- | | Secret exposure | Production tokens, private keys, and passwords should not be pasted into untrusted services. | | Local time vs UTC | Expiration and timestamp checks often fail because the displayed time zone is misunderstood. | | Match exactly | Hashes, keys, and encoded values must match character for character. | | Recovery plan | Passwords and 2FA flows need backup codes or an account recovery route. |

FAQ

Can I rely on the visible result alone?

No. Use the visible result to understand the value, then verify it with the backend, password manager, package signature, or official account recovery flow that controls the real system. In practice, pair this step with the output from Decode a JWT.

Common exp claim mistakes

The most common mistake is mixing seconds and milliseconds. JWT exp is normally a NumericDate in seconds, while JavaScript timestamps from Date.now() are milliseconds. If you compare them directly, a token may look valid or expired for the wrong reason.

Also remember that decoding a JWT payload only tells you what the token says. It does not prove that the token is authentic. For debugging, reading exp is useful; for access control, the backend still needs to verify the signature, issuer, audience, and expiration together.

Watch for clock skew

A token can fail near its expiration time if the client, server, and identity provider disagree by a few seconds or minutes. When debugging edge cases, compare the decoded expiration with server logs and the machine clock. Many systems use a small grace window, but that should be an explicit backend decision, not something assumed from the decoded payload.

Security checks that matter

Decode a JWT exp claim, convert NumericDate to local time, and understand why expired tokens should not be accepted. Security-related tools are useful for inspection, but the enforcing system still decides whether something is valid. A decoded token, generated password, or matching checksum should be checked against the backend, password manager, release page, or account policy that actually matters.

Use Decode a JWT with non-sensitive inputs when possible. If you need to inspect a real value, avoid pasting secrets into untrusted places, record the source of the expected result, and keep the final verification tied to the official system.