JWT: understand structure, signature, expiration and common mistakes

A JSON Web Token commonly contains three Base64URL-encoded parts: header, payload and signature. The payload is readable; a signed JWT is generally not encrypted.

Decoding is not verification

Anyone holding a JWT can decode its header and payload. That says nothing about whether the signature is valid or whether the issuer should be trusted. Use the JWT decoder to inspect structure and the JWT inspector to reason about claims, but verification belongs to trusted application code with the expected key and algorithm.

Validate more than the signature

Check expiration (exp) and, when used, nbf, issuer (iss) and audience (aud). Reject algorithms your application did not explicitly choose. Never let untrusted token metadata silently redefine verification rules.

Keep sensitive data out of the payload

Because the payload is readable, do not treat it as a secret store. Minimize claims and avoid unnecessary personal or confidential data.

Storage and sessions still matter

A valid token can still be stolen. Browser storage choices, cookie attributes, XSS defenses, token lifetime, refresh strategy and revocation requirements all affect risk. JWT is a token format, not a complete session architecture.

The JWT encoder is useful for learning and controlled workflows; production issuance and verification should remain server-side and policy-driven. Pair token design with sound password practices and authorization checks on every protected action.

For the broader relationship between authorization flows, PKCE and public keys, see OAuth 2.0, PKCE, JWT, JWK and JWKS.