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.

What is the JWT Registered Claim Reference?

Searchable reference of registered JWT claims from RFC 7519 and OpenID Connect — iss, sub, aud, exp, iat, jti and profile claims — each with type, meaning and an example value. It runs free in your browser on Gera Tools, with nothing uploaded.

JWT Registered Claim Reference

Name: JWT Registered Claim Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

The seven RFC 7519 registered claims in detail

RFC 7519 defines exactly seven claim names with reserved semantics. All are optional in the specification, but in practice most secure systems require several of them:

Claim	Type	Purpose
`iss`	String (URI)	Identifies the principal that issued the token
`sub`	String	Identifies the subject — typically a user ID
`aud`	String or array	Names the intended recipient(s)
`exp`	NumericDate	Token expiration time; reject after this moment
`nbf`	NumericDate	Token not valid before this time
`iat`	NumericDate	Time at which the token was issued
`jti`	String	Unique identifier for the token; enables revocation

NumericDate is always an integer count of seconds since the Unix epoch (1970-01-01 00:00:00 UTC). A common mistake is using milliseconds (as JavaScript’s Date.now() returns) — this produces an exp in the year ~50000 and the token never expires in practice.

OpenID Connect additions

OpenID Connect layers identity claims on top of the RFC 7519 base for ID tokens delivered to client applications. Common ones include name, email, email_verified, picture, locale, zoneinfo, phone_number, address, updated_at, auth_time, nonce, acr, amr, and azp. These let a client learn who the user is without making an additional userinfo endpoint call.

Of these, email_verified deserves extra attention: the presence of an email claim alone does not prove the user controls that address. Only treat the email as verified when email_verified is true.

Claims for access tokens (RFC 9068)

Access tokens presented to resource servers often carry additional claims beyond the identity set: scope lists what the bearer is authorised to do, client_id names the OAuth client, roles or groups may carry authorisation data, and cnf can pin the token to a specific cryptographic key. These are not in RFC 7519 but are commonly included by identity providers following RFC 9068 (JSON Web Token Profile for Access Tokens).