JWT Payload Explained: Claims Like sub, iss, aud and exp

The JWT payload is the second base64url segment and the part people actually read: a JSON object of claims such as sub, iss, aud, exp and iat. It answers the questions who is this token for, who issued it, and when does it stop working. Because the payload is only encoded, every claim in it is visible to anyone who holds the token. The claim names follow the JWT specification.

What does a decoded JWT payload look like?

A realistic payload carries both standardized claims and application-specific ones. Decode any token with the JWT Decoder to see its claims as formatted JSON:

{
  "sub": "1234567890",
  "name": "Alice",
  "iat": 1516239022,
  "exp": 1516242622,
  "aud": "api.example.com",
  "iss": "auth.example.com"
}

The registered claims follow the RFC 7519 names; name is a private claim the application added for its own use.

What is a claim?

A claim is a single assertion encoded as a key-value pair: sub names the subject, exp declares an expiry instant, and an application can add a claim for a role, a tenant or a plan. The word is borrowed from the JWT specification, which calls the whole payload set of claims. What matters is that a claim is only as trustworthy as the signature covering it - read the payload freely, but verify before you act on it.

What are the registered claims?

RFC 7519 defines seven registered claim names that are recognized across implementations. They are optional in the grammar, so a valid token may include some, all or none of them, but production tokens usually carry most:

A validator typically checks iss against the issuer it expects, aud against its own identifier, and exp against the current time. Those three checks, plus the signature, are the core of validating a JWT.

What are public and private claims?

Beyond the registered names, the specification distinguishes public claims, whose names come from the IANA JSON Web Token registry or are collision-resistant namespaced names such as https://example.com/role, and private claims, which are arbitrary names two parties agree on between themselves, like name or role in the sample above. The difference is only about naming discipline; all claims live in the same payload object.

Is the payload secret?

No, and this deserves emphasis because it is the most common JWT misconception. The payload is base64url-encoded, which is a plain text representation with no key involved. Anyone who intercepts or receives the token can decode the claims in a few seconds. The signature protects integrity, not confidentiality, so the payload must never contain a password, a session token or personal data you would not put in a log line.

If you genuinely need to hide claims, JWE (JSON Web Encryption) exists for that, but almost every JWT in the wild is a signed JWT with a readable payload. Design the claims as if they were public.

How much should a payload carry?

Keep the payload small on purpose. Every claim is sent with every request that uses the token, so a bloated payload adds bytes to each call and widens the surface of readable data. Put stable identifiers and role data in the token, and leave anything large - profile text, image lists, audit trails - on the server behind a fetch.

A lean payload is also easier to audit. When you can list every claim on one screen, checking that nothing sensitive leaked into the token is a quick review instead of a dig through hundreds of keys. Fewer claims means fewer places where a stale value can cause a wrong authorization decision.

How do you validate the claims in a payload?

Decoding shows you the claims, and validating decides whether to accept them. The JWT Validator checks the signature, confirms alg is an allowed algorithm, verifies that exp has not passed, and can compare iss and aud against expected values. In code, libraries such as jsonwebtoken take the same options - algorithms, issuer, audience and clock tolerance - and do the checks for you. Read with the decoder, trust only after validation.