JWT Claims Explained (exp, iat, nbf, iss, aud, sub, jti)
JWT claims live in the token payload and describe who the token is for, who issued it, and when it’s valid. Understanding these fields helps you debug auth issues and avoid subtle security mistakes.
Standard registered claims
| Claim | Meaning | Common pitfalls |
|---|---|---|
exp | Expiration time (Unix timestamp) | Clock skew; using ms instead of seconds |
iat | Issued at (Unix timestamp) | Inconsistent time sources; ms vs seconds |
nbf | Not before (valid starting time) | Users see “token not active yet” due to skew |
iss | Issuer identifier | Not validating issuer in services |
aud | Audience (who the token is intended for) | Accepting tokens for the wrong audience |
sub | Subject (often a user id) | Changing meaning across systems |
jti | Token id (unique identifier) | Not using it for revocation when needed |
Notes on timestamps
Most JWT libraries use seconds since epoch. If you accidentally store timestamps in milliseconds, everything looks far in the future.
Try it instantly
Decode a token locally in your browser: JWT Decoder.
Related
- JWT signature verification explained (HS256 vs RS256)
- Base64url vs Base64 (why JWT uses URL-safe Base64)
- Common JSON parse errors (fix payload formatting issues)
- JSON Formatter (format payload JSON)
- Base64 Decoder (JWT segments are Base64url)
- All tools