JWT Claims Reference
Part of the JWT Toolkit| Claim | Meaning | |
|---|---|---|
| iss | Issuer | RFC 7519 — who created and signed the token |
| sub | Subject | RFC 7519 — who the token is about (a stable ID, not an email) |
| aud | Audience | RFC 7519 — who the token is intended for; string or array |
| exp | Expiration Time | RFC 7519 — NumericDate after which the token is rejected |
| nbf | Not Before | RFC 7519 — NumericDate before which the token is rejected |
| iat | Issued At | RFC 7519 — NumericDate the token was created |
| jti | JWT ID | RFC 7519 — unique ID for this specific token |
| scope / scp | Granted permissions | OAuth2 convention — space-separated, e.g. "read:user write:user" |
| azp | Authorized Party | OIDC — the client the token was issued to |
| sid | Session ID | OIDC — identifies the session, used for single sign-out |
| nonce | Nonce | OIDC — ties an ID token back to the auth request, blocks replay |
| cnf | Confirmation | RFC 7800 — binds the token to a key the presenter must prove possession of |
Explanation
A JWT's payload is a JSON object, and every key in it is a claim — a statement about the token or the thing it represents. RFC 7519 reserves seven claim names with an agreed-upon meaning (below), OAuth2 and OpenID Connect layer a handful more on top, and anything beyond that is a custom claim whoever issued the token invented for their own purposes.
Three of the registered claims — exp, nbf, iat — are timestamps, and they're expressed as a NumericDate: an integer count of seconds since the Unix epoch, not an ISO 8601 string. That distinction is the single most common source of bugs in hand-rolled JWT code.
And it's worth repeating: claims are Base64URL-encoded, not encrypted. Anyone holding the token can read every claim in it without any key — the signature only proves the claims weren't tampered with, it doesn't hide them. For the full walkthrough of how each claim is actually used in practice, see JWT Claims Explained.
Valid examples
{"exp": 1735689600}A Unix timestamp (seconds since the epoch) — the correct NumericDate format for exp.
{"sub": "user_8f3c2a"}A stable, opaque account ID — won't change if the user's email or username does.
{"aud": ["api.example.com", "admin.example.com"]}An array form of aud, valid when a token is meant for more than one audience.
Invalid examples
{"exp": "2025-12-31T23:59:59Z"}An ISO 8601 string instead of a NumericDate — most JWT libraries expect integer seconds and will misread or reject this.
{"sub": "alice@example.com"}A mutable email used as the subject — if the user changes it, the subject silently stops matching account records.
{"password": "hunter2"}A secret placed directly in the payload — claims are Base64URL-encoded, not encrypted, so anyone holding the token can read this instantly.