JWT Claims Explained

A JWT's payload is just a JSON object, and each key in that object is called a claim — a statement about the token, the user it represents, or how long it's valid for. Some claim names are standardized and mean the same thing across every library and provider; most of the rest are specific to whoever issued the token. Here's what you'll actually run into.

The seven registered claims

RFC 7519 defines seven claim names as "registered" — reserved, with an agreed-upon meaning, though none of them are actually required to be present.

• iss (Issuer) — who created and signed the token, usually a URL identifying the auth server.
• sub (Subject) — who the token is about, almost always a user or account ID.
• aud (Audience) — who the token is meant for. A verifier is supposed to reject a token that doesn't list it as an intended audience. This one can be either a single string or an array of strings, since a token can be valid for more than one audience at once.
• exp (Expiration Time) — a Unix timestamp after which the token must be rejected, no matter how valid the signature is.
• nbf (Not Before) — a Unix timestamp before which the token must be rejected. Less common than exp, but useful for tokens that shouldn't be usable until some future point.
• iat (Issued At) — the Unix timestamp the token was created, mainly useful for auditing and for computing how old a token is.
• jti (JWT ID) — a unique identifier for this specific token, sometimes used to detect or block replay of the exact same token.

Notice that three of the seven — exp, nbf, iat — are timestamps expressed as raw seconds since the epoch, not human-readable dates. That's exactly the kind of value that's easy to misread by eye; our JWT Expiration Checker converts them and shows a live countdown to (or since) exp instead of making you do the math.

Claims that aren't in the JWT spec but show up everywhere

JWTs are used constantly as OAuth2/OIDC access and ID tokens, and that ecosystem has its own conventions layered on top of RFC 7519:

• scope or scp — the permissions granted to this token, usually a space-separated string like read:user write:user.
• azp (Authorized Party) — the client the token was issued to, used when that's different from the audience.

Neither of these is part of the JWT spec itself, but you'll see them constantly in tokens from Auth0, Okta, and most other OAuth2 providers.

Custom claims

Anything beyond the above is a custom claim — role, permissions, tenant_id, or a namespaced key like https://myapp.com/roles (a pattern some providers use specifically to avoid colliding with a future registered claim name). Custom claims mean whatever the issuer decided they mean; there's no spec to check against, so the only source of truth is that issuer's own documentation.

Claims are visible, not secret

It's worth repeating because it trips people up constantly: a JWT's claims are Base64URL-encoded, not encrypted. Anyone holding the token can decode and read every claim in it without any key at all — the signature only proves the claims haven't been tampered with, it doesn't hide them. Never put a password, secret, or anything confidential in a claim. If you need to confirm a token's claims actually came from a trusted issuer rather than being forged, that requires checking the signature — our JWT Inspector verifies HMAC-signed tokens, and the JWT Signature Verifier covers RS256/ES256 as well.

Try it yourself

Paste any token into our JWT Claims Viewer to see every claim broken out individually, tagged as standard or custom, with a plain-English explanation next to each one — or use the plain JWT Decoder if you just want the raw header and payload JSON. Both run entirely in your browser; nothing you paste is ever uploaded.