The Comprehensive Guide to JSON Web Tokens (JWT) & Claims Architecture
In modern API authentication, OAuth2, and OpenID Connect (OIDC) architectures, JSON Web Tokens (JWT) provide a compact, self-contained method for securely transmitting claims between distributed parties. Defined under RFC 7519, a JWT encodes user permissions, session expiration timestamps, and issuer identity into a URL-safe Base64URL formatted string.
Our JWT Decoder runs 100% client-side using in-browser Base64URL decoders. Because no network requests are dispatched, your sensitive production tokens, credentials, and user data remain strictly confidential.
1. JWT Structure & Standard Registered Claims Matrix
Review the breakdown of standard registered JWT claims defined under RFC 7519:
| Claim Key | Full Claim Name | Data Type & Example | RFC 7519 Description |
|---|---|---|---|
iss |
Issuer | String (e.g. "https://auth.company.com") |
Identifies the security principal that issued the JWT |
sub |
Subject | String (e.g. "usr_98a72b6") |
Identifies the primary subject (usually user ID or client ID) |
aud |
Audience | String / Array (e.g. "https://api.company.com") |
Identifies the recipients that the JWT is intended for |
exp |
Expiration Time | Unix Epoch Seconds (e.g. 1735689600) |
Timestamp on or after which the JWT MUST NOT be accepted |
iat |
Issued At | Unix Epoch Seconds (e.g. 1704067200) |
Timestamp identifying when the JWT was created |
2. Best Practices for Secure JWT Implementation
- Always Use Cryptographic HTTPS: JWT payloads are base64url encoded, NOT encrypted. Never place raw passwords or credit cards in payload claims.
- Enforce Explicit Algorithm Verification: Prevent algorithm confusion attacks by strictly disallowing
alg: "none"on your backend verification handlers. - Short-Lived Access Tokens: Set access token expiration (
exp) between 5 and 60 minutes, paired with long-lived refresh tokens stored in secure HttpOnly cookies.