use case

How to check a JWT expiry timestamp

Convert the 'exp' claim in a JWT payload from Unix seconds to a readable expiry date.

JWT tokens contain an 'exp' claim — a Unix timestamp in seconds indicating when the token expires. When a token is rejected with a 401 error, the first debugging step is to check whether it has expired. This guide shows how to convert the 'exp' value from a decoded JWT to a readable date and compare it against the current time.

Step-by-step guide

  1. Decode the JWT and find the exp claim: Use the JWT Decoder tool to paste your token and read the payload. Find the 'exp' field — it is a 10-digit Unix timestamp in seconds, for example 1716998400.
  2. Paste the exp value here: Copy the numeric value of 'exp' and paste it into the Timestamp Converter. The output shows the exact expiry date in UTC and the relative time — for example '3 minutes ago' (expired) or 'in 4 hours' (still valid).
  3. Compare against the current time: If the relative time says 'X minutes/hours ago', the token is expired and must be refreshed. If it says 'in X minutes/hours', the token is still valid. Also check the 'iat' (issued-at) claim the same way to verify the token was issued when expected.

Frequently asked questions

The exp shows a time far in the future — is the token never expiring?
Long-lived tokens are a valid but risky design. An expiry of years in the future means the token never needs refreshing, which increases the blast radius if it is stolen. If you did not intend this, check your token-signing code for a miscalculated expiry duration.
Can I set a specific expiry time when generating a JWT?
Yes. Convert your desired expiry date to Unix seconds here, then pass that value as the 'exp' claim when signing the token. For example, 'in 1 hour' = Date.now() / 1000 + 3600.

Try it now

Use the Unix Timestamp Converter to complete this task — free, no sign-up, runs in your browser.

Open Unix Timestamp Converter

We use cookies to serve ads and measure traffic. Cookie policy · Privacy policy