Developer Guide · 2026

How to Check If a JWT Is Expired: exp Claim, Libraries & Decoders

A JWT is expired when its exp claim — a Unix timestamp in seconds — is in the past. You can read that claim by hand, let jsonwebtoken, PyJWT, JJWT or .NET throw for you, or paste the token into a client-side decoder for an instant verdict. This guide shows all three ways, the epoch-to-date conversion, and leeway.

Written by Benjamin Rotshtein

Updated August 14, 2026

Download as PDF

How do you check whether a JWT has expired?

Decode the payload and compare the exp claim — a Unix timestamp in seconds — against the current time. If exp is in the past, the token is expired and every library will reject it. Add a small leeway window on both sides to absorb clock drift between the issuer and your servers.

Method 1: read the exp claim by hand

The payload is only Base64URL-encoded, never encrypted. Split the token on dots, decode the second segment, and read exp. Then compare it with the current Unix time. This needs no secret, no library and no server — the verdict is a single integer comparison.

// JavaScript — browser or Node
const [header, payload, signature] = token.split(".");
const claims = JSON.parse(
  Buffer.from(payload, "base64url").toString("utf8")
);
const expired = Math.floor(Date.now() / 1000) >= claims.exp;
console.log(expired ? "EXPIRED" : "valid");

# Python
import time, base64, json

claims = json.loads(base64.urlsafe_b64decode(
    token.split(".")[1] + "=="))
expired = int(time.time()) >= claims["exp"]
print("EXPIRED" if expired else "valid")

Two caveats: this tells you about expiry only — it does not prove the token is authentic. And if you don’t know whether the issuer applies leeway on its side, your local verdict may differ from theirs by a few seconds.

Method 2: let the library throw

Production code should not hand-roll the comparison. Every major library verifies the signature first, then checks exp (and often nbf / iat), and raises a dedicated exception:

// Node: jsonwebtoken
import jwt from "jsonwebtoken";
try {
  jwt.verify(token, secret);
} catch (err) {
  if (err instanceof jwt.TokenExpiredError) {
    console.log("expired at", err.expiredAt);
  }
}

# Python: PyJWT
import jwt
try:
    jwt.decode(token, key, algorithms=["HS256"])
except jwt.ExpiredSignatureError:
    print("EXPIRED")

// Java: jjwt
import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.ExpiredJwtException;

try {
  Claims claims = Jwts.parserBuilder()
      .setSigningKey(secret)            // HS256 key
      .build()
      .parseClaimsJws(token)
      .getBody();
} catch (ExpiredJwtException e) {
  System.out.println("EXPIRED at " + e.getClaims().getExpiration());
}

// C#: System.IdentityModel.Tokens.Jwt (.NET)
using System.IdentityModel.Tokens.Jwt;
using Microsoft.IdentityModel.Tokens;

var handler = new JwtSecurityTokenHandler();
var validation = new TokenValidationParameters
{
    ValidateLifetime = true,
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = new SymmetricSecurityKey(secret),
    ValidateAudience = false,
    ValidateIssuer = false
};
try
{
    handler.ValidateToken(token, validation, out _);
}
catch (SecurityTokenExpiredException e)
{
    Console.WriteLine("EXPIRED — token expired at " + e.Expires);
}

How the popular libraries behave

Convert the exp epoch timestamp to a readable date

exp is a Unix timestamp in seconds — a bare integer like 1789452110. To see the exact moment a token dies as a normal date, multiply by 1000 (JavaScript) or use the standard library (Python, Java, .NET). This is the conversion every “JWT expiration date converter” and decoder performs under the hood:

// JavaScript
const date = new Date(payload.exp * 1000);   // seconds -> ms
console.log(date.toISOString());             // 2026-08-14T11:03:22.000Z
console.log(date.toLocaleString());          // local, human-readable

# Python
from datetime import datetime, timezone
print(datetime.fromtimestamp(claims["exp"], tz=timezone.utc).isoformat())

In Java, Instant.ofEpochSecond(exp) and in .NET, DateTimeOffset.FromUnixTimeSeconds(exp) give the same answer. Note the claim has no timezone of its own — it is an absolute instant, so the human date you see depends on your local timezone (14:03 in UTC+3 is 11:03 UTC).

Leeway: the variable that changes the verdict

Every validator compares against its own clock, and clocks drift. Leeway makes validation succeed when now <= exp + leeway. Without it, a token minted by a server 2 seconds ahead of yours can fail seconds before its true expiry. With 30-60 seconds of leeway, small skew is absorbed — but keep leeway well below the token lifetime, or a token that should be dead can be resurrected for the duration of the grace period. If you see a server rejecting tokens that your local check says are valid, the first thing to compare is the two clocks, not the code.

Method 3: use a browser decoder for instant answers

When you hold a token and just want to know — is it expired, and exactly when did it die — the fastest answer is a JWT decoder. It reads the exp claim, converts it to a human-readable date, and compares it with your local clock — all in the browser, with the token never leaving your machine. That turns a “401 session expired” into “this token died 4 minutes ago at 14:03,” which immediately tells you whether the client is reusing a stale token or the server is minting them too short.

Frequently asked questions