JSON Web Tokens (JWTs) Explained

A JWT is like a signed note that a trusted adult gives you. The note might say, "This is Sofia. She already logged in. She can enter the blue room until 15:30." You can carry that note around and show it to different doors. The doors do not need to phone the trusted adult every time. They can check the signature on the note themselves.

That is the simple version. The real object is just a text string with three parts separated by dots:

1. Header
2. Payload
3. Signature

What is inside the token?

The header says what kind of token this is and which signing algorithm was used.

The payload contains claims, which are facts the sender wants the receiver to read. A claim might be a user ID, a role such as admin, an audience such as api.example.com, or an expiry time.

The signature is the important bit. The server takes the header and payload, runs them through a signing algorithm, and uses either a secret key or a private key to produce a signature. Another server can then verify that signature using the same secret or the matching public key.

What a JWT does well

JWTs are useful after login. Suppose you sign in once. The authentication server checks your password, then gives your app a JWT. Later, when your app calls an API, it sends the token along, often in an Authorization: Bearer ... header. The API verifies the signature, checks the expiry time, and decides whether the request is allowed.

This can be convenient because the API does not need to store a session record for every request. The token carries enough information for the API to make a decision.

What people get wrong

A JWT is not secret just because it looks messy. The header and payload are usually only base64url encoded. That is packaging, not encryption. Anyone who gets the token can decode those two parts and read them. So do not put passwords, card numbers, or private notes inside a normal JWT.

A JWT is also not magic revocation. If someone steals a valid token, they can often use it until it expires. That is why short lifetimes matter. Many systems pair short-lived access tokens with refresh tokens and keep extra server-side controls for logout, device revocation, or emergency blocking.

Why the signature matters

Imagine Leo changes the payload from role: user to role: admin. The text of the token changes. When the server verifies the signature, the maths no longer matches, so the token is rejected. That is the whole point of the signature: it proves the token was issued by someone holding the correct key and that the signed contents have not been altered.

Practical rules

A careful JWT design usually follows a few rules:

• keep the payload small
• include an expiry time
• validate issuer and audience, not just the signature
• never trust a JWT that says alg: none
• do not store sensitive secrets in the payload

So the kid-friendly summary is this: a JWT is not a locked treasure chest. It is a signed pass. Everyone can read the writing on the pass, but only the trusted issuer can create a signature that proves the pass is real.