WebUtils
EN

Developer Workflow

Check JWT expiration with Unix timestamps

Decode JWT exp and nbf claims, convert their Unix timestamps, and compare token expiry with API logs, browser sessions, and UTC incident notes.

Open Unix Timestamp Converter

Problem

JWT expiration bugs are easy to misread because exp, iat, and nbf are Unix timestamps, usually in seconds. If you compare those raw numbers with JavaScript milliseconds, local browser time, or UTC API logs, a token can look expired too early or valid too long.

When to use this

  • A JWT contains exp, iat, or nbf claims and you need to confirm the readable UTC expiration time.
  • An API returns 401 or 403 even though the user believes the login session is still active.
  • A backend log, browser console message, or mobile client error must be compared with the token lifetime.
  • You need a shareable debugging note without pasting the full token into a ticket.

Steps

  1. Step 1

    Decode the token claims locally

    Open JWT Decoder and paste only the token you are allowed to inspect. Copy the payload claims that include exp, iat, nbf, iss, aud, and sub.

  2. Step 2

    Copy the numeric time claims

    Keep the claim names next to the numbers, for example exp=1735689600 and nbf=1735686000. The claim name tells you whether the date is an expiration, issued-at, or not-before boundary.

  3. Step 3

    Convert the timestamps

    Paste the copied claims into Unix Timestamp Converter. Treat JWT exp, iat, and nbf as seconds unless your identity provider clearly documents another unit.

  4. Step 4

    Compare against UTC logs

    Compare the converted UTC times with API gateway logs, auth service logs, or browser network timestamps before switching to local time for a user-facing explanation.

  5. Step 5

    Write a redacted debugging note

    Share the converted claim times, issuer, audience, and status code. Do not include the raw token, signature, session cookie, or private user identifiers.

Example

Check whether a rejected access token expired

Input

JWT payload claims: iat=1735686000 nbf=1735686000 exp=1735689600. API gateway rejected the request at 2025-01-01T00:05:00Z.

Output

iat -> 2024-12-31T23:00:00.000Z
nbf -> 2024-12-31T23:00:00.000Z
exp -> 2025-01-01T00:00:00.000Z
The 2025-01-01T00:05:00Z request happened after expiration.

Common mistakes

Treating JWT seconds as JavaScript milliseconds

JWT time claims normally use Unix seconds. Multiplying or interpreting them as milliseconds changes the date and can hide the real expiration boundary.

Sharing the full token in a ticket

A JWT can contain sensitive claims and may still be valid. Share decoded, redacted claim names and converted times instead of the raw token.

Checking only exp and ignoring nbf

A token can be rejected before expiration if the not-before claim is in the future or if client clock skew makes the request look too early.

FAQ

Are JWT exp and iat values seconds or milliseconds?

JWT NumericDate claims are normally Unix seconds. Convert them as seconds unless a non-standard issuer explicitly documents milliseconds.

Should I paste a production JWT into a public ticket?

No. Decode it locally, redact sensitive claims, and share only the converted timestamps and non-sensitive context needed for debugging.

Why does the token fail before the exp time?

The nbf claim, issuer or audience mismatch, revoked sessions, clock skew, or server-side token policy can reject a token before the expiration claim.