JWT Claims Viewer
View and understand JWT payload claims—the data carried within the token. Claims contain user identity, permissions, and metadata used by your application.
Key Features
- Registered claims display
- Public claims identification
- Private claims extraction
- Claim value formatting
- JSON pretty printing
When to Use This Tool
Use to inspect what data is being transmitted in tokens, verify user permissions, or debug authorization issues.
Example
Common JWT claims: { "sub": "user_12345", "name": "Jane Developer", "email": "jane@example.com", "role": "admin", "permissions": ["read", "write", "delete"], "iat": 1699521200, "exp": 1699524800 }
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
- Registered claims (sub, iss, exp) have defined meanings—use them correctly
- Keep sensitive data out of claims—anyone can decode the payload
- Custom claims should use namespaced names to avoid collisions
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