JWT Lifetime Calculator

About the JWT Lifetime Calculator

JSON Web Tokens (JWTs) are the standard for stateless authentication in modern APIs. A well-designed JWT strategy uses short-lived access tokens (15–60 minutes) paired with longer-lived refresh tokens (7–30 days). Getting these lifetimes right is a balancing act between security (shorter = safer) and user experience (longer = fewer re-authentications).

This calculator helps you visualize JWT timing by showing exact Unix timestamps for `iat` (issued at), `exp` (expiry), and recommended refresh points for both access and refresh tokens. It also calculates the total number of token refreshes per day and per session, helping you optimize token lifetimes for your specific security requirements and usage patterns.

When This Page Helps

JWT lifetime configuration directly impacts both security and user experience. Too short and users face constant re-login friction. Too long and stolen tokens remain valid for extended periods. This calculator helps find the optimal balance and visualizes the complete token lifecycle.

How to Use the Inputs

1. Set the access token lifetime (recommended: 15–60 minutes).
2. Set the refresh token lifetime (recommended: 7–30 days).
3. View the generated timestamps (iat, exp) for each token type.
4. Check the refresh frequency and total refreshes per session.
5. Adjust lifetimes to balance security and user experience.

Example Calculation

Tips & Best Practices

• Never store JWTs in localStorage — use httpOnly cookies or memory.
• Access tokens of 15 minutes limit breach exposure while maintaining usability.
• Implement refresh token rotation: issue a new refresh token with each use.
• Include only necessary claims in JWTs to minimize token size.
• Use aud (audience) and iss (issuer) claims for multi-service environments.
• Implement refresh token revocation for logout and security events.

JWT Token Architecture

A well-designed JWT system uses two token types: short-lived access tokens for API authorization and longer-lived refresh tokens for obtaining new access tokens. This separation limits the exposure window while maintaining seamless user sessions.

Lifetime Recommendations by Use Case

Public API: Access 30–60 min, no refresh token. Web SPA: Access 15 min, Refresh 7 days. Mobile app: Access 30 min, Refresh 30 days. Microservices: Access 5 min, machine-to-machine refresh. Banking: Access 5 min, Refresh 1 day.

Security Considerations

Every minute of token lifetime is a window of opportunity for an attacker with a stolen token. Short access tokens with refresh token rotation minimize risk while maintaining usability. Always validate exp, iat, iss, and aud claims server-side.

Implementation Best Practices

Store access tokens in memory only (not localStorage). Store refresh tokens in httpOnly, Secure, SameSite cookies. Implement CSRF protection. Use PKCE for public clients. Monitor for refresh token reuse as a compromise indicator.

Frequently Asked Questions

• What is a good access token lifetime?

  For most web and mobile applications, 15–60 minutes is recommended. High-security applications (banking, healthcare) should use 5–15 minutes. Internal tools with lower risk profiles can use 30–60 minutes.

• How long should refresh tokens last?

  Refresh tokens typically last 7–30 days. Mobile apps often use 30–90 day refresh tokens for better user experience. Browser-based apps should use shorter refresh tokens (1—7 days) due to higher theft risk.

• Should I use sliding expiration for refresh tokens?

  Sliding expiration (extending the refresh token on each use) improves UX but extends the window for compromised tokens. A hybrid approach with an absolute maximum lifetime (e.g., 90 days) and sliding window within that provides good balance.

• What goes in the JWT exp claim?

  The exp claim is a Unix timestamp (seconds since epoch) representing when the token becomes invalid. It is set to the issued-at time plus the TTL. Servers must reject tokens with exp earlier than the current time.

• Can JWTs be revoked before expiry?

  JWTs are stateless, so they cannot be directly revoked. Strategies include: maintain a blocklist of revoked tokens (adds state), keep access token TTL very short, or use token binding. Refresh tokens can be revoked server-side.

• What is refresh token rotation?

  Each time a refresh token is used to obtain a new access token, a new refresh token is also issued and the old one is invalidated. This detects theft: if a stolen refresh token is used after the legitimate user has already used it, the reuse is detected and all tokens are revoked.