Developer tools · JWT decoder
The Seven Registered JWT Claims: iss, sub, aud, exp, nbf, iat and jti
· Background
jwt data-formats authentication
RFC 7519 reserves seven claim names with defined meanings and types. This post explains each one, the StringOrURI and NumericDate types behind them, and how registered, public and private claims coexist.
Which claim names should I use? — the design question the registry answers
Choosing claim names is partly an interoperability decision. Reusing a registered name gives readers and libraries an established meaning, while application-specific names require local documentation. ToolAcre recognises seven core names in its description table and leaves other claims visible without assigning semantics.
A familiar name is not automatically trustworthy. The decoder reads whatever object the token contains and never verifies its signature. Registered vocabulary helps humans classify data; only a trusted verifier can establish that an issuer supplied the protected value.
iss and sub are displayed as strings; this implementation does not enforce StringOrURI syntax
`iss` identifies who the token claims issued it, and `sub` identifies who or what it is about. ToolAcre describes both and displays their values, but its implementation does not validate a StringOrURI grammar or compare either field with service configuration.
A verifier should bind the expected issuer to trusted key material and interpret subject under that issuer’s namespace. Copying a known issuer string into a fabricated payload makes the decoder look convincing without establishing origin. Use these fields only after cryptographic verification.
aud — the intended recipients, as a string or an array
`aud` describes intended recipients and may be represented as one value or a list under applicable token rules. ToolAcre’s generic claims table preserves arrays as JSON text but does not decide whether the current service appears in them.
Audience is contextual. The same authenticated token may be appropriate for one API and wrong for another. A resource server needs an expected identifier in trusted configuration and must reject a mismatch rather than letting the token define where it should be accepted.
exp, nbf and iat — the three NumericDate claims that bound a token in time
`exp`, `nbf` and `iat` are NumericDate claims. ToolAcre treats finite numbers as seconds since the epoch, multiplies by 1,000 for Date display and labels expiry or not-before relative to the browser clock. It does not define leeway or enforce server acceptance.
An expiry marks a claimed end boundary, not proof that the token was ever valid. Not-before marks a claimed start boundary, and issued-at records a claimed creation time. Each can be forged in a payload, so time arithmetic must follow signature verification in a trusted flow.
jti — a unique identifier for replay detection and denylists
`jti` is a token identifier. Systems can use an authenticated, suitably generated identifier for replay tracking or revocation state, but the claim alone does not provide either property. ToolAcre describes it as a token id for replay detection and displays its exact value.
Uniqueness, storage and lookup behavior belong to the issuer and verifier architecture. A decoder cannot determine whether another token reused the identifier or whether a denylist contains it. Treat it as a candidate correlation value until the surrounding trusted system supplies evidence.
Registered descriptions and application-specific claims in the ToolAcre display
The implementation distinguishes registered names only through explanatory text. Every payload property is still returned by `listClaims`; unknown names receive a null description and the UI labels them application-specific. It does not consult a public registry or prevent private-name collisions.
That boundary avoids claiming more than source proves. Teams should document their private claims and choose collision-resistant names when interoperability matters. The decoder’s absence of a description means “not in this local seven-name table,” not “invalid” or “safe to ignore.”
Worked example — reading a realistic payload and classifying each claim
Consider `{"iss":"https://issuer.example","sub":"user-7","aud":["orders"],"exp":1717246800,"nbf":1717243100,"iat":1717243200,"jti":"demo-9","tenant":"north"}`. ToolAcre describes the seven registered fields and labels `tenant` application-specific while formatting the three numeric times.
This classification helps review payload design. It does not authenticate the URL, subject, audience, dates, identifier or tenant. A forged token can reproduce the object exactly. Feed only verified claims into authorization logic, then apply the consuming service’s expected values.
Takeaway: use the registered names when they fit — the ToolAcre JWT decoder shows the payload so you can see which claims a real issuer sets
Use registered names when their defined meanings fit, because recognizable vocabulary reduces needless translation. Keep private fields documented and minimal. Do not overload `sub`, `aud` or a time claim with a different local meaning merely because downstream code already parses that key.
ToolAcre can show which names a safe token carries and how its numeric claims render. It cannot certify any value. The useful outcome of decoding is an inventory for review; the useful outcome of verification and policy is a decision, and those remain separate.