2026-09-09

JWT Claims Cheat Sheet

A reference for the claim names you'll see inside almost every JWT payload. Paste a token into the JWT Debugger to see its actual header, payload, and signature broken out.

Standard registered claims

These are defined by RFC 7519 and, while none are strictly required, most JWTs use several of them:

Claim	Name	Meaning
iss	Issuer	Who issued the token (e.g. an auth server's identifier)
sub	Subject	Who the token is about - typically a user or account ID
aud	Audience	Who the token is intended for - a specific API or service
exp	Expiration time	Unix timestamp after which the token is no longer valid
nbf	Not before	Unix timestamp before which the token must not be accepted
iat	Issued at	Unix timestamp when the token was issued
jti	JWT ID	A unique identifier for this specific token, often used to prevent replay

Common custom claims

Beyond the registered set, most real-world JWTs carry application-specific claims - there's no fixed list since these are defined by whoever issues the token, but common ones include:

Claim	Typical meaning
email	The user's email address
name	The user's display name
roles / scope / permissions	Authorization data - what the bearer is allowed to do
iss-specific IDs (e.g. org_id, tenant_id)	Multi-tenant or organization context

Custom claims can be anything the issuer wants - always check the specific API or auth provider's documentation for what it actually puts in the payload.

A genuinely important security point

A JWT's header and payload are Base64URL-encoded, not encrypted. Anyone holding the token - not just its intended recipient - can decode the payload and read every claim in it, including anything you assumed was private. The signature only proves the token wasn't tampered with after issuance; it does nothing to hide the payload's contents.

Practical implications:

• Never put secrets, passwords, or sensitive personal data directly in JWT claims - treat the payload as visible to anyone who can intercept or inspect the token.
• Decoding a JWT (what the JWT Debugger does) requires no key or secret at all - it's just Base64 decoding, the same reason it can run entirely client-side.
• Verifying a signature is a separate operation from decoding, and does require the signing key or secret - decoding tells you what a token claims, verification tells you whether it's trustworthy.

Try JWT Debugger · More cheat sheets · All tools