JWT Standard Claims Reference: What Every Claim Means

A JWT payload is a JSON object containing claims — statements about the subject and the token itself. The IANA JSON Web Token Claims Registry defines seven standard registered claims that appear in nearly every JWT you will encounter. Paste your token into the decoder above to see its claims decoded instantly.

The Seven IANA Registered JWT Claims

These are the standard claims defined in RFC 7519. All are optional by the spec, but most implementations use several of them:

• sub (Subject): Identifies who the token is about — usually a user ID like user_12345 or an email address. This is the most commonly used claim for identifying the authenticated user.
• iss (Issuer): Identifies who issued the token. Often a URL like https://auth.example.com or a service name. Useful when your app accepts tokens from multiple identity providers.
• aud (Audience): Identifies the intended recipients of the token. A string or array of strings — your API should verify the token was issued for it specifically.
• exp (Expiration Time): Unix timestamp (seconds since epoch) after which the token must not be accepted. Always a number, not a date string.
• iat (Issued At): Unix timestamp when the token was issued. Useful for determining token age and implementing max-age policies.
• nbf (Not Before): Unix timestamp before which the token must not be accepted. Less common — used for tokens that become valid in the future.
• jti (JWT ID): A unique identifier for this specific token. Used to prevent replay attacks by tracking used token IDs in a blocklist.

How to Read exp and iat Timestamps

The exp and iat claims are Unix timestamps — the number of seconds elapsed since January 1, 1970 UTC. A value like 1735689600 is not human-readable on its own.

The JWT decoder above automatically converts these to readable dates. If you want to convert manually:

# In browser console
new Date(1735689600 * 1000).toISOString()
// "2025-01-01T00:00:00.000Z"

# Python
import datetime
datetime.datetime.fromtimestamp(1735689600)
# datetime.datetime(2025, 1, 1, 0, 0)

Note: multiply by 1000 in JavaScript because JS uses milliseconds, not seconds.

To check if a token is expired, compare exp to the current time: if exp is less than Date.now() / 1000, the token has expired.

Sell Custom Apparel — We Handle Printing & Free Shipping

Registered, Public, and Private Claims

JWT claims fall into three categories:

• Registered claims: The seven IANA-defined claims above (sub, iss, aud, exp, iat, nbf, jti). Short names to keep tokens compact.
• Public claims: Custom claims defined in the IANA JWT Claims Registry to avoid collisions — things like email, name, picture. OpenID Connect uses many public claims.
• Private claims: Custom claims agreed upon between two parties — for example role, org_id, permissions. Not registered anywhere; only meaningful within your own system.

When you decode a JWT from Auth0, Firebase, or Supabase, you will typically see a mix: registered claims (sub, iss, exp, iat) plus provider-specific public claims (email, email_verified, name) plus any custom private claims your app adds.

Common OpenID Connect Claims

If your JWT comes from an OpenID Connect provider (Auth0, Google, Firebase, Keycloak, Supabase), you will see additional claims beyond the base seven:

• email — the user's email address
• email_verified — boolean, whether the email has been verified
• name — full display name
• given_name / family_name — first and last name
• picture — URL of the user's profile photo
• nonce — random value to prevent replay attacks in the auth flow
• at_hash — hash of the access token (for ID tokens)

These follow the OpenID Connect Core spec and are consistent across compliant providers. Paste your OIDC token above to see all claims decoded and labeled.

Frequently Asked Questions

Are all seven registered JWT claims required?

No — all registered claims are optional per RFC 7519. However, exp and iat are strongly recommended for security. Many auth libraries will reject tokens missing exp.

Can the same claim name be used as both a registered and a private claim?

You should avoid it. If you add a custom "sub" or "exp" claim with a different meaning, it will conflict with the standard. Use namespaced private claims like "https://yourapp.com/role" to avoid collisions.

Is it safe to decode JWT claims in the browser?

Decoding is safe — it is just base64url decoding. But never put sensitive secrets in JWT payloads, since anyone who has the token can decode and read the claims without a key.

What is the difference between iat and nbf?

iat (Issued At) records when the token was created. nbf (Not Before) sets a future activation time — the token cannot be used before that timestamp even if it was issued earlier.