What's inside a token
A JWT is three Base64url strings joined by dots: header.payload.signature. The header is JSON that names the signing algorithm, like {"alg":"HS256","typ":"JWT"}. The payload is JSON claims: sub for who the token is about, iss for who issued it, aud for who it's meant for, and iat and exp for when it was issued and when it expires. The signature covers the first two parts joined by a dot.
Times are Unix timestamps in seconds. A token with iat 1767225600 and exp 1767226500 was issued at 2026-01-01T00:00:00Z and expires 15 minutes later. An HS256 signature is 43 characters long, and RSA signatures are longer.
Nothing in the token is encrypted. Base64url is an encoding, not a lock, so never put passwords or personal data in the payload.
Readable doesn't mean trusted
Anyone can decode a JWT, and anyone can write one. A decoder only reads the Base64url. The signature is what makes a token worth trusting: it's an HMAC or a public key signature over the header and payload, so changing one character of either breaks it. Only a server that checks the signature with its own key can tell a real token from a forged one.
The key and the algorithm come from the server's configuration, never from the token. The header's alg is a claim made by whoever built the token. RFC 8725 tells libraries to let the caller name the algorithms they'll accept and to refuse none unless asked. The decode vs verify guide shows the difference on a real token. HS256 and RS256 sign in different ways, and which one you pick decides who can mint tokens.
What a server checks
After the signature checks out, the claims still need a look:
exp: the token must not be accepted on or after this time.nbf: the token must not be accepted before this time.iss: the issuer is one you trust.aud: your service is in the audience. If the claim is there and you're not listed, reject the token.- Algorithm: it's one you expect, and it fits the key you hold.
If any check fails, the token is rejected, and RFC 7519 says so outright. The registered claims guide covers each claim, and the exp, nbf and iat guide covers clock problems.
Lifetime and revocation
A signed token stays valid until exp, even if the user logs out or the account is closed, unless the server also keeps a list of revoked tokens. That's why access tokens are kept short and paired with a refresh step. A token that lives 15 minutes limits a thief to that window, and a token that lives 1 day gives them 96 times as long. The access token lifetime guide has ranges that work, and JWT vs session cookies covers when a plain session is the better fit.