§ 6.1Anatomy of a JWT
A JWT is three Base64url strings joined by dots: a header (which algorithm signed it), a payload of claims, and a signature. The header and payload are only encoded, not encrypted — anyone holding the token can read them, which is exactly what this page does.
§ 6.2Registered claims
| Claim | Meaning |
|---|---|
iss | Issuer — who created the token |
sub | Subject — usually the user ID |
aud | Audience — who the token is for |
exp | Expiry, in seconds since 1970 (Unix time) |
nbf | Not valid before this time |
iat | Issued at |
jti | Unique token ID |
Note the units: JWT times are in seconds. A value 1,000 times too large usually means someone wrote milliseconds.
§ 6.3What not to trust
- Decoding is not verification. Your server must check the signature with the right key before trusting any claim.
- Pin the algorithm. Never accept
alg: none, and don’t let the token choose between HMAC and RSA — that is a known attack. - Don’t put secrets in the payload. It is readable by anyone.
- Pasting real tokens: this page runs entirely in your browser, but a live token is a password while it is valid. Prefer expired or test tokens anywhere you are unsure.
§ 6.QQuestions
Can this verify the signature?
No. Verification needs the secret or public key, and it should happen on your server.
Why does it say “no exp claim”?
The token has no expiry. That is allowed by the standard but risky — it stays valid until the key changes.
§ 6.RReferences
Last reviewed 2026-10-14.