JWT exp and nbf Guide | Reading Expiry and Not Before

First Read

Most JWT timing bugs come from interpretation, not the raw numbers

`exp`

This marks when the token should stop being accepted. The problem is that server time, proxy time, and the operator's local view can all differ.

`nbf`

This marks when the token should start being accepted. Immediate failures right after issue time often point here first.

`iat`

It tracks issue time and is not always enforced directly, but it becomes useful when you compare all timing claims together.

Common Failures

What shows up in real incidents

Seconds vs milliseconds

JWTs usually use Unix seconds. When frontend code or logs treat them as milliseconds, the resulting timestamps look completely wrong.

Decoding without verification

Readable tokens are not automatically trustworthy. External issuer setups still need signature validation through JWKS or an equivalent check.

Ignoring environment drift

Even a small time difference between application and auth servers can create repeated boundary failures. Teams should document acceptable skew explicitly.

Workflow

The pages to pair with this guide

Start on the JWT decoder to inspect the header and payload quickly.
Use the timestamp converter to translate exp, nbf, and iat into human time.
When you need the full request flow, open the API Request Tester alongside it.

Open JWT decoder Open timestamp converter Back to guide hub

Real input and output

The claims that decide expiry

Input

{
  "sub": "user-123",
  "iat": 1767225600,
  "nbf": 1767225600,
  "exp": 1767229200
}

Output

iat issued at   2026-01-01 00:00:00 UTC
nbf valid from  2026-01-01 00:00:00 UTC
exp expires     2026-01-01 01:00:00 UTC
Lifetime 1 hour

All three are epoch seconds. Passing milliseconds pushes the value tens of thousands of years out and effectively disables expiry checks.

A token whose nbf is in the future

Input

now 1767225600, nbf 1767229200

Output

Not yet usable — valid one hour from now

Errors you will hit

A valid token is rejected as expired

Clock drift between servers is the usual cause. If the issuer runs slightly ahead, nbf is still in the future for the receiver. Most libraries expose a clock skew tolerance, commonly 30 to 60 seconds — check that first.

exp set in milliseconds

RFC 7519 time claims are in seconds. Passing Date.now() directly inflates the value by 1000 and issues a token that never expires. This is a security incident waiting to happen, so audit the issuing code.

Decoding is not verifying

A JWT header and payload are Base64URL encoded, not encrypted. Anyone can read them and re-encode modified content. Only a passing signature check makes a token trustworthy, and secrets must never go in the payload.