What are JWT fields?
JWT fields are usually called claims: name/value pairs in the payload that communicate information to the system consuming the token. The JWT specification defines registered names, but it does not make every registered claim mandatory for every token. The expected claims and their meaning depend on the application and protocol.
The following table summarizes the standard registered claim names most developers encounter. Treat their presence and value as input to a verifier's policy, not as proof of trust by themselves.
Common registered JWT claims
| Field | Meaning | Practical note |
|---|---|---|
iss | Issuer | Identifies the principal that issued the token. Compare it with a trusted expected issuer. |
sub | Subject | Identifies the subject. The application defines the expected interpretation. |
aud | Audience | Identifies the intended recipient or recipients. Reject a token not intended for the current recipient when audience validation is required. |
exp | Expiration time | Token must not be accepted on or after this NumericDate under normal rules. |
nbf | Not before | Token must not be accepted before this NumericDate under normal rules. |
iat | Issued at | Time the token was issued. It is not automatically proof of freshness or validity. |
jti | JWT ID | Identifier for this token; systems may use it for tracking or replay-related controls. |
JWT time fields: exp, nbf and iat
The common time claims use NumericDate values—typically seconds from the Unix epoch, 1 January 1970 UTC. A decoder that interprets the number as milliseconds will show a wildly incorrect date, so inspect the unit before troubleshooting.
exp: the token must not be accepted on or after the expiration time, subject to any explicitly configured small clock-skew allowance.nbf: the token should not be accepted before the not-before time.iat: records when the token was issued. Application policy can use it to evaluate age, but its presence does not validate the token.
A browser-based inspector can compare numeric dates with the local clock to surface likely timing issues. A production verifier must use its own trusted time and validation configuration.
Custom JWT fields
Tokens often contain application-specific fields such as role, tenant, permissions or a feature flag. Those names are not automatically registered claims. Their meaning comes from the issuer-consumer contract, and the server must apply the required authorization rules.
Do not infer a user’s privileges from an unverified role field displayed by a decoder. Claims become useful for security decisions only within a correctly validated token and authorization design.
Which JWT fields should an application validate?
There is no one list that fits every JWT. The application should define required claims for its use case and validate their type, value and semantics after verifying the signature. Common checks include trusted issuer, intended audience, expiry, not-before time and any application-specific requirements. For access tokens, also follow the applicable OAuth/OIDC profile and current security guidance.
Pin allowed algorithms in verifier configuration. Do not dynamically trust the algorithm or key source just because a token header specifies it. Keep keys in trusted configuration or a trusted key-discovery path linked to the expected issuer.
References and further reading
Primary standards and documentation used to support this guide.
Frequently asked questions
Are JWT fields mandatory?
No. The JWT specification defines registered claim names, but it does not require every token to include every registered claim. The application or protocol profile determines which claims are required.
What is the difference between iss and aud?
iss identifies the issuer that created the token; aud identifies the recipient or recipients for whom the token is intended.
What is the difference between exp, nbf and iat?
exp is the expiry time, nbf is the earliest time the token should be accepted, and iat is when it was issued.
Are custom claims safe to trust?
Not by their presence alone. The token must be cryptographically and contextually validated, and the application must define how each custom claim affects behavior.
What time unit does exp use?
JWT NumericDate values are typically seconds from the Unix epoch. Use the specification and token issuer's contract if your system defines a profile-specific interpretation.
Put the explanation to work.
Inspect a token in the browser-based JWT formatter, then use the claims reference when you need to understand a field.