JWT (JSON Web Token) is a token standard that apps use to confirm a user is authenticated. If you build APIs or debug authentication, sooner or later you'll need to look inside a token. Let's see how it's structured.
What a JWT looks like
It's a long string made of three parts separated by dots:
xxxxx.yyyyy.zzzzz
- Header — which signing algorithm is used.
- Payload — the actual data: who the user is, when the token expires, what permissions they have.
- Signature — protection against tampering.
The first two parts are just data encoded in Base64. That means they can be read.
What "decode" actually means
Strictly speaking, a JWT isn't encrypted, it's encoded. The Header and Payload are Base64 of plain JSON (see what is Base64). Anyone can decode them and see the contents. That's why you should never put secrets in a JWT — passwords, card numbers. It should only contain things that are fine to show.
How to view a token's contents
Open the JWT decoder tool, paste in the token, and you'll see the Header and Payload broken down in a readable form: the username, expiration time (exp), granted permissions (scope/roles), and other fields. Decoding happens locally in the browser — the token is never sent anywhere.
Why a token can't be forged
If the contents can be read, why can't you just change "regular user" to "administrator"? Because of the third part — the signature. It's computed from the header, the payload, and a secret key known only to the server. Change the payload, and you break the signature, so the server rejects the token. Verifying the signature without the key is impossible — that's what provides the protection.
Useful payload fields
exp— expiration time (Unix time; a time converter can turn it into a date).iat— when the token was issued.sub— the user identifier.
If the exp field is in the past, the token has expired and the server won't accept it, even if the signature is valid.