JWT Claims Decoder — Full Breakdown of All JWT Claims
Decode · Inspect · Verify · Generate JSON Web Tokens — expiry countdown, security warnings, HS256 verify — 100% browser-side
JWT claims are the heart of token-based authentication — they carry the user identity, permissions, and token metadata that your application uses for authorization decisions. This claims decoder shows every claim with its RFC 7519 name, a plain-English description, and formatted value — making it easy to understand exactly what your token contains and whether it has the right claims for your use case.
What is a JWT Decoder?
A JWT Decoder reads a JSON Web Token and displays its three parts in human-readable format. Every JWT contains a Header (algorithm & type), a Payload (claims — user data, expiry, issuer), and a Signature. This tool decodes all three instantly, shows expiry status with a live countdown timer, highlights standard claims with labels, detects security issues like alg:none, and supports HS256/HS384/HS512 signature verification using the browser Web Crypto API.
JWT Structure — How It Works
A JWT looks like xxxxx.yyyyy.zzzzz — three Base64URL-encoded strings joined by dots. The header and payload are readable by anyone; the signature is what proves authenticity. Only the party holding the secret or public key can verify the signature. This means JWTs should never contain sensitive data like passwords.
Frequently Asked Questions
What is the sub claim in a JWT?
sub (Subject) is the unique identifier of the user or entity the token represents — typically the user's database ID or UUID. It's the most important claim for identifying who is making the request. Example: "sub": "user_abc123" or "sub": "usr_12345678". It should be stable and never change for a given user.
What is the aud claim and why does validation fail?
aud (Audience) specifies which service the token is intended for — your API's identifier or URL. When validating, your server must check that its own identifier is in the aud list. If you use a token from Service A on Service B, validation fails because the aud doesn't match. This prevents token misuse across services.
How are custom claims different from registered claims?
Registered claims (iss, sub, aud, exp, nbf, iat, jti) are defined by RFC 7519 with specific meanings. Custom claims are any additional data you add — like roles, email, tenant_id, subscription_tier. Custom claims should use collision-resistant names (namespaced like "https://myapp.com/roles") to avoid conflicts with future standards.
Should I store user permissions in JWT claims?
For small, stable permission sets (3-5 roles): yes, storing in JWT avoids a database lookup on every request. For large or frequently-changing permissions: no — the token can grow too large and stale permissions require token revocation. Best practice: store role names in JWT, but look up fine-grained permissions from cache/DB when needed.
What is the scope claim in OAuth 2.0 JWTs?
scope defines what actions the token is authorized to perform — a space-separated string of permissions like "read:users write:posts delete:own". Scopes are requested during OAuth authorization and granted based on user consent and app permissions. Your API checks the scope claim before allowing sensitive operations.