What is inside a token
A JWT is three parts separated by dots. The first two are Base64url-encoded JSON that anyone can read; the third is a signature.
- Header — the signing algorithm (
alg) and the type (typ). Services that rotate keys also carry akidpointing at the key used. - Payload — the claims.
subidentifies the user,issthe issuer,audthe intended recipient, andexp,iatandnbfcarry times. - Signature — the first two parts signed with a key.
The spec defines the time claims as integer seconds. A token that put milliseconds there shows up here as thousands of years in the future, which points at a bug on the issuing side.
Decoding is not verifying
Reading the contents here says nothing about whether the token is genuine. The payload is not locked, anyone can rewrite it, and only the holder of the key can tell that the signature no longer matches.
That is why the server has to verify the signature on every request — and must not trust the alg field while doing so. Pin the expected algorithm on the server and reject anything that says none or disagrees with what you expect. Implementations that follow the header blindly are the classic way unsigned tokens get accepted.
Keep secrets out of the payload
Anyone with the token, including anyone looking at browser devtools, can read the payload. If it carries a national ID, an internal admin note or payment details, treat those as published.
What belongs there is what you would not mind the bearer seeing: a user id, role names, an expiry. Everything else stays on the server and gets looked up when needed.
Before pasting someone else’s token
This tool does not send the token anywhere. Still, a token that has not expired is a credential: paste it into a chat room or an issue tracker and anyone reading can use it. If one leaks, revoke that session rather than waiting for the expiry.