JWT Expiry Checker

When Should I Use This?

This tool is specifically designed to help debug authentication failures. You should use it when:

• Your frontend application starts receiving sudden 401 Unauthorized or 403 Forbidden errors from your API.
• You are testing token refresh logic and need to manually verify if the newly generated tokens have the correct expiration extensions.
• You are dealing with Cross-Origin Resource Sharing (CORS) or OAuth flows and need to verify the token payload before passing it to backend microservices.

Troubleshooting API Authentication Errors

Issue: The API rejects the token but the expiry date looks correct.
Fix: The most common cause is Clock Skew. Your backend server's system clock might be slightly ahead of or behind the token issuer's clock. A token issued by an auth server might instantly be rejected by a resource server if their NTP clocks are off by a few seconds. To fix this, always add a 5-60 second "clock skew allowance" in your JWT verification middleware.

Understanding JWT Time Claims: exp, iat, and nbf

JSON Web Tokens (RFC 7519) rely on three primary numeric date claims to govern their valid lifetime. All three of these claims use numeric Unix timestamps (seconds since January 1, 1970).

• exp (Expiration Time): The exact date and time after which the JWT must not be accepted. If the current time is past the exp value, the token is invalid.
• iat (Issued At): The time at which the JWT was generated. This is used to determine the age of the token.
• nbf (Not Before): The time before which the JWT must not be accepted. If a token is received before its nbf time, it should be rejected. This is useful for issuing tokens that become active in the future.

Because servers process Unix timestamps effortlessly, this format is highly efficient for machine-to-machine validation. However, for a human developer trying to debug a 401 Unauthorized response, a string like 1738249033 is meaningless at first glance. You need a tool to convert that epoch time into a readable date format.

That is exactly where a dedicated JWT expiry checker comes in. Our tool automatically decodes the base64url payload segment, extracts these time claims, and instantly calculates the times in your specific local timezone. By running strictly in your browser, it ensures that your sensitive tokens never leave your local environment.

Timezone Handling & Clock Skew

One of the biggest frustrations when debugging JWTs is timezone conversion. Most online tools decode Unix timestamps into UTC by default. If you live in New York, London, or Tokyo, comparing a UTC timestamp against your local system clock requires mental math that can easily hide a 5-hour configuration bug.

How our tool handles timezones: When you paste a token, this checker reads your browser's native timezone API. It then converts the Unix timestamp into a localized, human-readable date and time formatted exactly for where you are sitting right now.

When validating time claims in your own code, remember to account for Clock Skew. Distributed systems rarely have perfectly synchronized clocks. If your token was generated on Server A and validated on Server B, a 5-second difference in their system clocks might cause an nbf or exp validation failure. Most JWT validation libraries (like jsonwebtoken for Node) allow configuring a "leeway" or "clockTolerance" (typically 30-120 seconds) to tolerate this clock drift.

Stop Decoding JWTs Manually

Every developer has done it: copy a JWT from a response header, open a new browser tab, navigate to a JWT website, paste the token, and then manually calculate whether the exp timestamp has passed. Even worse, most tools display the time in UTC, forcing you to do timezone math in your head.

This tool does one thing and does it perfectly. Paste a token, and you immediately see the expiry time in your own timezone with a clear EXPIRED or VALID badge. If you need a more advanced inspection of the token header, payload, and cryptographic signature, use our full JWT Debugger.

Because this is a ZeroData tool, your JWT — which may contain user IDs, roles, and session information — never touches a server. The entire decode happens via JavaScript's atob() in your browser.

Production Examples & Real-world Use Cases

Developers use our local JWT expiry checker for several daily workflows:

• Debugging Authentication Errors: When your frontend suddenly gets 401 Unauthorized or 403 Forbidden errors, you can quickly check if the token has naturally expired or if there is a permission issue.
• Testing Token Lifetimes: After modifying your identity provider (e.g., Auth0, Cognito, Keycloak), paste the generated token here to verify the newly configured jwt exp value reflects a 15-minute lifespan rather than a default 24-hour lifespan.
• Verifying Clock Skew: Distributed systems often experience clock drift. If your server rejects a token that appears valid, comparing the exp time against your local clock can reveal synchronization issues.

Deep Dive: Handling Token Revocation and The Stateless Dilemma

The greatest architectural advantage of JSON Web Tokens is that they are completely stateless. Your API servers can mathematically verify a token's integrity and expiration without querying a central database. However, this creates a profound security dilemma: If a JWT is perfectly valid and hasn't reached its exp time, how do you revoke it if the user clicks "Log Out" or if their account is compromised?

Since you cannot 'un-sign' a token or ask the token to invalidate itself, you have three architectural patterns to handle revocation:

• Short Lifespans + Refresh Tokens (Recommended): Keep the JWT exp incredibly short (e.g., 5-15 minutes). If a token is stolen, the attacker only has minutes to use it. The client uses a stateful, database-backed "Refresh Token" to get new JWTs. When the user logs out, you simply delete the Refresh Token from the database. The active JWT will naturally expire moments later.
• The Token Blocklist (Deny List): When a user logs out, extract the jti (JWT ID) claim and store it in a highly performant key-value store (like Redis) with a TTL (Time-To-Live) matching the token's remaining exp. Your middleware must check this blocklist on every request. This re-introduces state, but only for revoked tokens.
• Key Rotation (Nuclear Option): If a massive breach occurs, you can rotate the asymmetric signing keys (JWKs) or change the symmetric HMAC secret. This instantly invalidates every single active JWT across your entire system, forcing all users to re-authenticate.

Command-Line (CLI) Automation: Decoding JWTs Natively

While this browser-based tool is perfect for quick visual debugging, backend engineers and DevOps practitioners often need to inspect JWTs inside headless Linux servers, CI/CD pipelines, or Docker containers. Because the JWT payload is simply Base64URL encoded JSON, you can decode the exp claim directly from your terminal using standard GNU utilities like jq and base64.

# 1. Store your token in an environment variable
export TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MzgyNDkwMzN9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

# 2. Extract the payload (the middle section), fix Base64URL padding, decode, and parse with jq
echo $TOKEN | cut -d '.' -f 2 | tr '_-' '/+' | awk '{print $1"=="}' | base64 --decode 2>/dev/null | jq .

# 3. Specifically extract the 'exp' claim and convert the Unix timestamp to a human-readable local date
EXP_TIMESTAMP=$(echo $TOKEN | cut -d '.' -f 2 | tr '_-' '/+' | awk '{print $1"=="}' | base64 --decode 2>/dev/null | jq -r .exp)
date -d @$EXP_TIMESTAMP

Integrating snippet checks like this into your bash scripts allows you to programmatically verify if service-account tokens are expiring soon and automatically trigger rotation scripts before a production outage occurs.

Troubleshooting Common JWT Expiry Issues

If your application is inexplicably dropping user sessions or rejecting API calls, investigate these common pitfalls:

• Timestamps in Milliseconds: The most common bug in custom JWT implementations is setting the exp claim using JavaScript's Date.now() (which returns milliseconds) instead of seconds. This causes the token to theoretically expire thousands of years in the future, rendering expiration useless. Always use Math.floor(Date.now() / 1000).
• Missing 'exp' Claim: Not all tokens enforce an expiration date. If your system depends on session invalidation on the server, you might intentionally omit the exp claim. However, for stateless JWTs, omitting it is a severe security vulnerability.
• NTP Sync Failures: If your backend API nodes are running on distinct VMs or bare metal servers without strict NTP (Network Time Protocol) synchronization, Server A might issue a token with an iat that Server B considers to be in the future, instantly rejecting it.
• Corrupted Signatures & Malformed Tokens: If your token was copied incorrectly or truncated during an HTTP redirect, decoding the payload might fail entirely. Since this checker only reads the payload, it won't detect signature tampering. If you suspect tampering, you should rigorously verify the cryptographic signature using our JWT Signature Verifier.

You should also check out our JWT Security Complete Guide to learn about signing algorithms, the none-attack, and secure token storage best practices.

If you need to create test tokens with specific expiry times, use our JWT Generator. To check if a token's cryptographic signature is actually valid, use the JWT Signature Verifier. For managing the keys used to sign these tokens, check out our JWK Generator and JWK to PEM Converter.

Looking for other offline developer utilities? You can visually configure CORS rules using our CORS Header Generator or clean up local environment configs with our ENV File Formatter.