JWT exp in Milliseconds – Fix an Expiration Date Far in the Future

Local only

Recognize a 13-digit exp timestamp that was encoded in milliseconds instead of JWT NumericDate seconds.

94 chars · 1 line

121 chars · 10 lines

Algorithm: HS256Signature not verifiedTime status: Active by exp/nbfExpires: +055840-11-08T22:13:20.000Z

JWT NumericDate unit issue

Why a JWT exp claim can decode to the year 55840

JWT NumericDate values use seconds from the Unix epoch. If application code inserts a JavaScript millisecond timestamp such as 1700000000000 directly into exp, the decoder interprets those digits as seconds and produces an expiration tens of thousands of years in the future. This tool is free to use. No account or payment is required.

Last updated

What you can do here

  • Browser-local JWT decoding
  • Strict three-segment validation
  • Canonical Base64URL checks
  • Header and payload JSON validation
  • Expiration status details
  • No signature verification claims

Steps

  1. Inspect the raw numeric exp value in the decoded payload.
  2. A typical contemporary Unix-seconds value is about 10 digits, while JavaScript milliseconds are about 13 digits.
  3. Convert milliseconds to seconds in the issuer before signing the token.

JWT timestamps are seconds, not Date.now() milliseconds

The decoder multiplies NumericDate seconds by 1000 only when creating the JavaScript Date used for display. Supplying milliseconds in the claim effectively applies that conversion twice.

Milliseconds used as exp

The 13-digit value is interpreted as seconds by JWT NumericDate semantics.

Incorrect exp

"exp":1700000000000

Decoder detail

Expires: +055840-11-08T22:13:20.000Z

Common questions

Frequently asked questions

Why is the year so large?

The claim contains milliseconds, but JWT NumericDate uses seconds.

Should I divide exp by 1000 when reading it?

Fix the issuer instead. Consumers should not need custom unit guessing for a standard NumericDate claim.

Does a far-future date prove the token is valid?

No. Signature and policy verification are still separate requirements.

Recommended next steps

JWT exp Claim Is a StringFix an exp claim encoded as text instead of a NumericDate number.JWT iat in the FutureInspect a future issued-at timestamp without confusing decoding with policy validation.Unix Timestamp Converter OnlineConvert iat and exp NumericDate values to readable UTC timestamps.

Debugging a specific JWT issue? Browse JWT troubleshooting.