JWT Expiry Checker
Check JWT token expiration to determine if a token is still valid. This tool converts Unix timestamps and shows remaining validity time in a human-readable format.
Key Features
- Expiration time extraction
- Human-readable time display
- Time remaining calculation
- Validity status indicator
- Timezone handling
When to Use This Tool
Use to quickly check if access tokens need refreshing, debug "token expired" errors, or verify token lifetimes match your security policy.
Example
Expiry check results: Token expires: December 15, 2024 3:45:00 PM UTC Time remaining: 47 minutes 32 seconds Status: ✓ Valid
Or: Token expired: December 15, 2024 2:30:00 PM UTC Expired: 1 hour 15 minutes ago Status: ✗ Expired
JWT Structure Explained
JSON Web Tokens consist of three Base64URL-encoded parts separated by dots:
1. Header: Contains the token type ("JWT") and signing algorithm (e.g., HS256, RS256) 2. Payload: Contains claims—statements about the user and additional metadata 3. Signature: Created by signing the header and payload with a secret key
Each part can be decoded independently, but only the signature verification confirms the token's integrity.
Standard JWT Claims Reference
| Claim | Name | Description |
|---|---|---|
| iss | Issuer | Identifies who issued the token |
| sub | Subject | Identifies the user or entity |
| aud | Audience | Intended recipient(s) of the token |
| exp | Expiration | Unix timestamp when token expires |
| nbf | Not Before | Unix timestamp when token becomes valid |
| iat | Issued At | Unix timestamp when token was created |
| jti | JWT ID | Unique identifier for this token |
Common JWT Algorithms
| Algorithm | Type | Description | Use Case |
|---|---|---|---|
| HS256 | Symmetric | HMAC with SHA-256 | Simple APIs with shared secret |
| HS384 | Symmetric | HMAC with SHA-384 | Higher security symmetric signing |
| HS512 | Symmetric | HMAC with SHA-512 | Maximum symmetric security |
| RS256 | Asymmetric | RSA with SHA-256 | Distributed systems, public verification |
| RS384 | Asymmetric | RSA with SHA-384 | Higher security asymmetric signing |
| RS512 | Asymmetric | RSA with SHA-512 | Maximum asymmetric security |
| ES256 | Asymmetric | ECDSA with P-256 | Mobile apps, smaller signatures |
| PS256 | Asymmetric | RSA-PSS with SHA-256 | Modern RSA replacement |
Where JWTs Are Used
JWTs have become the standard for modern authentication and authorization:
- Single Sign-On (SSO): Share authentication across multiple applications and services
- API Authentication: Secure REST and GraphQL APIs with stateless token verification
- OAuth 2.0 / OpenID Connect: Industry-standard protocols use JWTs for access and identity tokens
- Microservices: Pass user context between services without database lookups
- Mobile Applications: Lightweight authentication for iOS and Android apps
- Third-Party Integrations: Securely exchange data with external services
Pro Tips
- Refresh tokens before they expire, not after—use a buffer (e.g., refresh when 5 minutes remain)
- Access tokens should have short lifetimes (15-60 minutes)
- Refresh tokens can last longer (days/weeks) but should be rotated
Security Considerations
1. Signature verification: Always verify the signature on your server—never trust unverified tokens 2. Algorithm confusion: Validate the "alg" header to prevent attackers from using "none" or switching from RS256 to HS256 3. Token storage: Use httpOnly cookies when possible; localStorage is vulnerable to XSS attacks 4. Minimal payload: Include only necessary data—tokens should be small and not contain sensitive information 5. Token lifetime: Use short-lived access tokens (15-60 minutes) with refresh token rotation 6. Secret management: Keep signing keys secure; rotate them periodically; never expose them in client-side code 7. Token revocation: Plan for emergency revocation using token blacklists, version numbers, or short lifetimes