Anatomy: header, payload and signature
What each part contains, the standard claims and how signing algorithms differ.
1. Header
{ "alg": "HS256", "typ": "JWT" }It declares the signing algorithm (alg) and token type. For tokens signed with a key pair it may also carry a kid, a key identifier that tells the verifier which public key to use.
2. Payload (claims)
{ "sub": "123", "name": "Ana", "iat": 1700000000, "exp": 1700003600 }Registered claims have standard meanings:
| Claim | Meaning |
|---|---|
iss | Issuer: who created the token |
sub | Subject: who the token is about, usually a user id |
aud | Audience: who the token is for |
exp | Expiration time, in seconds since 1970 UTC |
nbf | Not before: not valid until this time |
iat | Issued at |
jti | Unique token id |
3. Signature
The signature is computed over base64url(header) + "." + base64url(payload) with a key. If anyone changes the payload, the signature no longer matches and verification fails.
HS256 vs RS256
- HS256 (HMAC-SHA256) is symmetric: the same secret signs and verifies. Everyone who can verify can also forge tokens, so keep it among trusted services.
- RS256 and ES256 are asymmetric: a private key signs and a public key verifies. Many services can verify tokens without being able to create them.
NoteThe decoder shows the times in human form. exp and iat are Unix timestamps in seconds, not milliseconds.
Test yourself
Answer all the questions, then check them. Finish with every answer right to mark the lesson as done.