What the three segments hold
A JWT is three pieces of URL-safe Base64 joined by dots. The header names the signing algorithm. The payload carries the claims. The signature is computed from the first two.
Only the signature is cryptographic. The header and payload are encoded, not encrypted, so anyone holding the token can read every claim in it. Never put anything in a payload that you would not want a stranger to read.
Some claim names have fixed meanings. sub is who the token is about, iss is who made it, and aud is who it is for. The window it is good for comes from iat, nbf and exp. Those three are Unix timestamps, so this page turns them into dates and says whether the token has gone stale.
- Algorithms
- HS256, HS384 and HS512 are checked right here. RS and ES tokens decode, but need a public key.
- Expiry
- exp, nbf and iat are turned into UTC dates, with how long ago or how long to go.
- Secret handling
- A secret you paste is used for the check and then dropped. It is never stored or sent.
- Malformed tokens
- A wrong segment count, bad Base64 or broken JSON is named, with the character at fault.
Verification matters more than decoding
Decoding tells you what a token claims. Verifying tells you whether to believe it. A token whose signature has not been checked is just input from a stranger.
The classic mistake is letting the token pick its own algorithm. That means accepting alg: none, or reading the algorithm out of the header and trusting it. On a server, pin the algorithm and the key you expect and ignore what the header says.