JWT Expired But Token Looks Valid Fix

A decoded JWT can look fine while still being expired, not yet valid, signed with the wrong key or meant for a different audience.

Symptoms

  • Token decodes correctly but the API rejects it.
  • exp appears far in the past or far in the future.
  • Only one server rejects the token.

Likely causes

  • exp, iat or nbf use milliseconds instead of seconds.
  • Server clock skew makes the token appear expired or not yet valid.
  • aud, iss or signature verification fails even though payload decoding works.

Fix steps

  1. Decode claims and convert timestamps to UTC.
  2. Compare token time against server time.
  3. Verify signature and expected issuer/audience on the backend.

Verify the fix

  • Generate a fresh token and test immediately.
  • Check server NTP/time sync.
  • Log auth failure reason without exposing token values.

FAQ

Does decoding prove a JWT is valid?

No. Decoding only reveals payload. Signature and claims must be verified.

Are JWT times seconds or milliseconds?

Standard JWT NumericDate values are seconds.

Related tools and guides

JWT JWT Decoder

Decode JWT header and payload locally, inspect common claims, and catch expiration or audience mistakes without sending tokens to an API.

 Time Unix Timestamp Converter

Convert Unix timestamps to readable dates, generate current timestamps and debug log, JWT and scheduling issues.

 JSON JSON Validator and Formatter

Validate JSON, format it for reading, or minify it for compact API payloads without sending data to an external API.

 JWT Debug JWT exp, iat and nbf Claims

JWT time bugs often come from seconds versus milliseconds, timezone confusion or trusting decoded payloads without signature verification.

Last updated: May 18, 2026