What is actually inside a JWT, and why you can read it without the secret
A JSON Web Token looks like noise: three blocks of letters and numbers separated by dots. It is not noise, and it is not encrypted. Anyone who has the token can read everything in it. Understanding that single fact prevents most JWT security mistakes.
The three parts
Split a JWT on its dots and you get a header, a payload, and a signature. The header and payload are just JSON, encoded with base64url so they survive being passed in HTTP headers. The header says which algorithm signed the token. The payload carries the claims: who the user is, when the token expires, and whatever else the issuer put in it.
Decode a JWTDecode JWT headers and payloads, inspect claims, and check expiry. Decode only, nothing is sent anywhere.What the signature actually does
The third part is not more data; it is a cryptographic signature over the first two parts. The server that issued the token computed it using a secret key. When the token comes back, the server recomputes the signature and compares. If anything in the header or payload changed, even one character, the signatures will not match and the token is rejected.
So the signature provides integrity and authenticity, not secrecy. It proves the token was issued by someone holding the key and has not been modified. It does nothing to hide the contents.
The claims worth knowing
exp: expiry time, in seconds since 1970. After this, the token must be rejected.iat: when the token was issued.sub: the subject, usually the user ID.issandaud: who issued the token and who it is for. Servers should check both.
What this means in practice
Never put secrets in a JWT payload: no passwords, no API keys, no personal data you would not show the user. The user can read their own token in two clicks. Keep tokens short lived, since anyone who steals one can use it until it expires. And always verify the signature server side; decoding a token tells you what it claims, but only verification tells you whether to believe it.