What are the seven registered claims in RFC 7519?

iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (JWT ID). They are all optional in the spec but most are required in practice for secure validation, especially exp, iss and aud.

What format is the exp claim?

exp, nbf, iat and auth_time use NumericDate: the number of seconds (not milliseconds) since the Unix epoch in UTC, ignoring leap seconds. A validator rejects a token once the current time passes exp, and refuses it before nbf.

What is the difference between registered, public and private claims?

Registered claims are defined in IANA's registry and have reserved meanings. Public claims are defined elsewhere but registered to avoid collisions. Private claims are custom names agreed between parties; namespace them with a URI or vendor prefix to prevent clashes with future registered claims.

Should I always check the aud claim?

Yes. The audience claim names the intended recipient. A resource server must reject a token whose aud does not include its own identifier, otherwise a token meant for one API could be replayed against another. Validate iss, aud, exp and nbf on every request.

Does this tool decode my JWTs online?

No. This page is a static reference table filtered in your browser. It does not accept or transmit tokens. Use a dedicated JWT decoder for inspecting a specific token, and never paste production tokens into untrusted tools.

JWT Registered Claim Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Every registered JWT claim, with type and meaning

A JSON Web Token carries a set of claims in its payload. Some claim names are registered with IANA and have fixed meanings; using them consistently lets any compliant library validate a token. This reference lists the RFC 7519 standard claims plus the common OpenID Connect profile claims, each with its data type, a description and an example value.

How it works

A JWT payload is a JSON object of name/value pairs. Registered claims like iss, sub, aud, exp, nbf, iat and jti drive validation; OpenID Connect adds identity claims such as email and name to ID tokens. Time claims use NumericDate — seconds since the Unix epoch.

{
  "iss": "https://auth.example.com",
  "sub": "user-12345",
  "aud": "api.example.com",
  "exp": 1735689600,
  "iat": 1735603200,
  "scope": "openid profile email"
}

A verifier checks the signature, then asserts exp is in the future, nbf is in the past, and that iss and aud match what it expects.

Tips and notes

Always validate exp, nbf, iss and aud — a valid signature alone does not make a token safe to trust.
Keep tokens short-lived and use jti plus a deny-list if you need revocation.
The nonce claim ties an ID token to the authentication request and defends against replay in OpenID Connect.
Namespace any custom claims (for example with a URI prefix) so they never collide with future registered names.