Understand JWTs in 10 Minutes

The three parts

A JWT looks like xxxxx.yyyyy.zzzzz. Split on the dots and you get three parts:

1. Header — base64url-encoded JSON describing the algorithm and type, e.g. {"alg":"HS256","typ":"JWT"}.
2. Payload — base64url-encoded JSON carrying the claims: who the token is for (sub), who issued it (iss), when it expires (exp), and when it was issued (iat).
3. Signature — bytes proving the header and payload were not tampered with, produced with the algorithm from the header.

Because header and payload are only encoded, anyone can read them. That is why you never put secrets in a JWT payload.

Reading claims

The most important registered claims:

• exp — expiration, a Unix timestamp in seconds. Reject tokens after this time.
• iat — issued-at timestamp. Useful for rotating short-lived tokens.
• sub — subject (usually the user id).
• iss/aud — issuer and audience; verify both on the server.

The trap: decoding is not verifying

Paste any token into a decoder and you see its claims. That proves nothing. An attacker can craft a token with "role":"admin" and encode it themselves — it will decode perfectly. Signature verification on your server is what stops that: recompute the signature with the shared secret (HS256) or the issuer's public key (RS256) and compare. Only then trust the claims.

Which algorithm to prefer

Use RS256 (asymmetric) when third parties need to verify tokens without holding your secret, or HS256 (symmetric) when only your own service issues and verifies. Reject tokens whose alg header you did not expect — the notorious alg:none attack exploits servers that trust the header blindly.

Practice with the decoder

Open ToolsKit's JWT decoder, paste a real token from your own app, and read its exp and iat. Then encode your own header/payload with the Base64 tool and see how trivial it is to forge claims without a signature check.