JWT exp (Expiration) Claim

The exp (expiration time) claim is one of the most critical registered claims in a JSON Web Token. It defines the exact moment after which the token must no longer be accepted for processing. The value is a NumericDate: the number of seconds since the Unix epoch (1970-01-01T00:00:00Z), not milliseconds.

How exp works in practice:

When a server receives a JWT, it compares the current time against the exp value. If the current time is equal to or greater than exp, the token is rejected. Most JWT libraries handle this automatically, but they typically allow a small clock skew tolerance (often 30-60 seconds) to account for time differences between servers.

{
  "sub": "user123",
  "iat": 1700000000,
  "exp": 1700003600
}

In this example, the token expires exactly one hour (3600 seconds) after it was issued.

Choosing the right lifetime:

Short-lived tokens (5-15 minutes) are more secure because a stolen token has limited utility. Long-lived tokens (hours or days) improve user experience by reducing re-authentication frequency. The best practice is to use short-lived access tokens combined with longer-lived refresh tokens. For API access tokens, 15 minutes is a common choice. For session tokens in web apps, 1-24 hours is typical depending on security requirements.

Security implications:

Without an exp claim, a token remains valid indefinitely, which is dangerous if the token is ever leaked or stolen. Always include exp in every JWT you issue. Note that exp alone does not provide revocation capability; once issued, the token remains valid until expiration. For immediate revocation, you need a token blacklist, short lifetimes, or a database-backed session check.

Common pitfalls:

JavaScript uses milliseconds for timestamps while JWT uses seconds, so dividing Date.now() by 1000 is necessary. Failing to do this is a frequent source of bugs where tokens expire billions of seconds in the future.