Configure JWT access and refresh token lifetimes. See timestamps for issued, expiry, and refresh schedule with recommended TTL ranges.
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.
Tracking this metric consistently enables technology teams to identify system performance trends and address potential issues before they impact end users or business operations. This measurement provides a critical foundation for capacity planning and performance budgeting, helping teams align infrastructure resources with application requirements and growth projections.
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. Precise quantification supports capacity planning and performance budgeting, ensuring infrastructure investments are right-sized for both current workloads and projected future growth.
Access exp = iat + access_ttl_minutes × 60. Refresh exp = iat + refresh_ttl_days × 86400. Refreshes per day = 1440 / access_ttl_minutes. Total refreshes = refresh_ttl_days × refreshes_per_day.
Result: Access: 15min, Refresh: 14d | 96 refreshes/day
A 15-minute access token means re-authentication every 15 minutes if the refresh token is available. Over a 14-day refresh token lifetime, there would be approximately 1,344 access token renewals for a continuously active user. The recommended refresh point is at 12 minutes (80% of TTL).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.