JWT Debugger
Debug and troubleshoot JWT issues by inspecting token structure, claims, and timing. This debugger helps identify why tokens might be rejected or cause authentication failures.
Key Features
- Visual token breakdown
- Claim inspection
- Timestamp conversion
- Expiration status
- Header analysis
When to Use This Tool
Use when authentication fails unexpectedly, tokens are rejected, or you need to understand what data a token contains.
Example
Common debugging findings: • Token expired 2 hours ago (exp: 1699524800) • Wrong audience claim (expected: api.myapp.com) • Missing required claim (no "role" in payload) • Algorithm mismatch (token uses RS256, server expects HS256)
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
- Compare timestamps carefully—JWT uses Unix timestamps in seconds
- Check for extra whitespace or newlines when copying tokens
- Verify the token was not truncated during transmission
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