JWT payloads use registered claim names defined in RFC 7519. Understanding these claims is essential for secure token-based authentication.
The exp claim sets a Unix timestamp after which the token must be rejected. Always include expiry in production JWTs to limit the window of misuse if a token is leaked.
The iss claim identifies the entity that issued the JWT — typically your authentication server URL. Validate this on every request to ensure tokens come from a trusted source.
The sub claim identifies the principal the token is about — typically a user ID. Treat sub as a stable, opaque identifier across systems.
The aud claim specifies the intended recipient of the JWT. Validate aud to prevent tokens issued for one service from being accepted by another (confused deputy attacks).
JWT Standard Claims Explained exists to read the standard claims: iss, sub, aud, exp, nbf, and iat, and know which ones your API must enforce. It is not a second copy of the tool homepage. The homepage introduces the whole product. This page stays on one job so a search for that job lands on instructions you can follow without hunting through other tabs. Read the result on this page against the input you actually used. A screenshot without the input is not evidence. If the result surprises you, change one thing and run it again before you change your VPN, browser, or server config.
Work through JWT Standard Claims Explained in order. 1. Find each claim in a real token on the decode page. 2. Write down which claims your API checks. 3. Confirm aud is your audience and not a different service. 4. Reject tokens that are outside exp and nbf. Write down the input and the output together. When you ask someone for help, send both. Repeat the same input once. A stable tool returns the same answer. If it does not, the input changed or the page is talking to a different network path than you think.
A claim is a statement. The signature is what makes it the issuer's statement. Custom claims are not standard just because they are in the JSON. This page does not verify a token. Treat the output as a measurement, then decide. RookVPN does not log the contents of a client-side tool, and a measurement is not a promise that every other app on the device behaves the same way. Compare a second path when the decision matters: a terminal command, another browser, or the matching guide linked below.
Example: aud is api.example and your service is admin.example. A valid signature does not make the token yours. You reject on audience. exp in the past is a second, independent reject. Logging the subject for a token you rejected on audience is fine. Accepting it is not.
After you finish JWT Standard Claims Explained, open the verify page to check the signature, then come back to the claims if the next question is different from the one this page answers. Stay here if you are still on the same job. Extra pages help only when they answer a new question, such as a different algorithm, a different leak channel, or a different file type. The documentation link on this page is the long form of the same workflow, including the checks that do not fit in the tool UI.
exp is the expiration time claim — a Unix timestamp after which the JWT must be rejected. It is defined in RFC 7519 Section 4.1.4.
sub is the subject claim — a unique identifier for the entity the JWT represents, typically a user ID or account identifier.
aud (audience) specifies which service or API the JWT is intended for. Validating aud prevents token reuse across unintended services.
The audience. Your service should be in it.
Not before. A token that is not yet valid.
If your policy requires it, reject. Do not fill it in from a header the client sent beside the token.