JWT Expiry Checker Online
Check JWT token expiry status, time remaining, and inspect standard claims (exp, iat, nbf, iss, sub, aud).
When a JWT expiry checker is the right tool
Use this page to see whether a compact JWT is inside its exp / nbf window, and to read the usual registered claims, without sending the token anywhere. Paste a token or click Load Sample; the status updates as you type. “Valid” is not a cryptographic judgment — the signature is never checked. To view header and payload in more detail, use JWT Decoder.
Use cases
Checking whether a test token has already expired
Paste the token. If exp is in the past, the banner is red and shows how long ago it expired, plus the local expiry date. If it is still in the future, the banner is green and shows time remaining.
Tokens with no exp, or a future nbf
A payload without a numeric exp is labeled “No expiry set (exp claim missing)” in yellow. If nbf is still in the future, you see “Not yet valid” (unless the token is already expired, which takes priority).
Reading iss, sub, and aud
Those claims appear in the table when they are present and truthy. An array aud is joined with commas. Custom claims stay out of the table but are included when you Copy Payload.
How the check works
The token is trimmed and split into three parts. The header and payload are base64url decoded (with a UTF-8 fallback if needed) and parsed as JSON. exp, iat, and nbf are compared to Date.now() in seconds. The algorithm row shows header.alg and header.typ only — a reminder of what the token claims, not a verified result. Load Sample uses a demo token whose exp is 9999999999 (20 November 2286 UTC).
Sample token payload (after Load Sample):
{
"sub": "user_1234",
"name": "Jane Doe",
"email": "jane@example.com",
"role": "admin",
"iat": 1700000000,
"nbf": 1700000000,
"exp": 9999999999
}
Status: Valid — expires many years from now (exp is 2286-11-20 UTC).
Signature is displayed only as the alg/typ from the header — it is not verified.Jane Doe and the admin role are in the payload JSON you can copy, but they are not rows in the claims table. The sample’s signature is not checked.
What this tool does not do
It does not verify HMAC or public-key signatures, refresh a token, or list every custom claim in the table. Remaining time does not tick by itself. Nothing is uploaded. To mint a new HS256 token, use JWT Generator.
How to use JWT Expiry Checker
- Paste a compact JWT, or click Load Sample.
- Read the status banner, then the claims table and the algorithm line.
- Use Copy Payload if you want the full JSON, or Clear to empty the input.
Frequently asked questions
Does this page verify the JWT signature?
No. It only base64url-decodes the header and payload and looks at time claims. “Valid — expires in …” means the exp timestamp is still in the future (and nbf, if present, is not in the future). A forged token with a far-future exp will be labeled Valid. Use JWT Decoder if you want to read the same parts plus the raw signature segment; neither page checks the signature against a key.
Which claims are shown, and how is status decided?
The claims table lists exp, iat, nbf, iss, sub, and aud when they are present. exp, iat, and nbf are used only if they are JSON numbers (a numeric string is ignored). Status is: no exp → “No expiry set (exp claim missing)”; exp in the past → “Expired {time} ago”; else if nbf is in the future → “Not yet valid (nbf is in the future)”; otherwise “Valid — expires in {time}.” An expired token that also has a future nbf is reported as expired. A future iat is not treated as invalid.
In which time zone are the timestamps shown?
Dates are formatted with the browser’s local time zone and the en-US locale, including a short time-zone name. Remaining and elapsed durations use seconds, then minutes and seconds, then hours and minutes, then days and hours.
Does the remaining time tick live? What does Copy Payload do?
The current time is read when the page renders, so the remaining-time text updates when you type or otherwise re-render, not every second on its own. Copy Payload writes the entire decoded payload JSON — including custom claims that are not listed in the table, such as name or email on the sample token.
What counts as an invalid token?
The input is trimmed and split on “.”. It must have exactly three parts, and the first two must base64url-decode to JSON. Otherwise you see “Invalid JWT — token must have 3 parts separated by dots.” (The same message is used when the part count is right but the JSON is not.) The third part is not decoded or verified. Load Sample pastes a fixed demo token with exp 9999999999; Clear empties the box.
Is my token sent to a server?
No. Decoding runs in your browser. A JWT can still be a credential: do not paste a production access token if you would not be comfortable with it sitting in memory on this device. Closing the tab discards it.
Related tools and guides
References
- RFC 7519 defines
exp,nbf, andiatas NumericDate values (seconds since the Unix epoch). This page treats only JSON numbers as those claims. - Status here is a time-window check only. A server must still verify the signature and any audience or issuer constraints before trusting a token.