JJWT Decoder

Developer reference

JWT Claims Cheat Sheet

A practical guide to registered JWT claims, what each claim means, and how to validate tokens safely in real applications.

Decode a JWT
Claim
Name
Meaning
Validate
Common mistake
iss
Issuer
Identifies the authority that issued the token.
Compare against the exact issuer URL or identifier you trust.
Accepting tokens from any issuer because the signature is valid.
sub
Subject
Identifies the principal the token is about, usually a user ID.
Treat it as an identifier, not as proof of permissions by itself.
Using an email address as a permanent subject when users can change email.
aud
Audience
Identifies the API, service, or client the token is intended for.
Reject tokens whose audience does not include your application.
Reusing an access token meant for one API against another API.
exp
Expiration Time
Unix timestamp after which the token must not be accepted.
Reject expired tokens, allowing only a small clock-skew window if needed.
Decoding exp for display but forgetting to enforce it server-side.
nbf
Not Before
Unix timestamp before which the token must not be accepted.
Reject tokens used before this time.
Ignoring nbf in systems that issue scheduled or delayed-validity tokens.
iat
Issued At
Unix timestamp showing when the token was issued.
Use it for age checks, auditing, and suspicious-token detection.
Treating iat as an expiration policy without also checking exp.
jti
JWT ID
Unique token identifier used for replay protection or revocation.
Store or check it when your system supports token revocation.
Adding jti but never using it in revocation or replay checks.

JWT validation checklist

  • Verify the signature with the expected algorithm and key.
  • Reject tokens using unexpected algorithms, including none.
  • Check iss, aud, exp, nbf, and any required custom claims.
  • Keep sensitive data out of JWT payloads because JWTs are encoded, not encrypted.
  • Use short-lived access tokens and rotate refresh tokens when possible.
  • Perform authorization checks on the server, not only in frontend code.

FAQ

Are JWT claims encrypted?

No. Standard JWT payloads are encoded, not encrypted. Avoid putting passwords, API keys, private profile data, or payment information into a JWT payload.

What custom claims are safe?

Custom claims should be minimal and non-sensitive, such as role IDs, tenant IDs, feature flags, or permission scopes that your server still validates.