2026-06-01 · 6 min read
JSON Web Tokens (JWTs) carry claims between services in a compact, URL-safe string. They appear in OAuth 2.0 access tokens, session cookies, and microservice headers. Understanding their structure helps you debug authentication without mistaking readability for trust.
The three parts
A JWT is header.payload.signature, each part Base64url-encoded. The header describes the signing algorithm. The payload holds claims such as subject (sub), expiration (exp), and audience (aud). The signature proves integrity only when verified with the correct secret or public key.
- Header — typ, alg
- Payload — business claims and standard registered claims
- Signature — cryptographic proof (when verified server-side)
Decoding vs verifying
Decoding reveals JSON content to humans. Verification confirms the token was issued by a trusted party and was not tampered with. Never authorize requests based on decode output alone. Always verify signatures (or use opaque tokens validated server-side).
Safe practices
Use test tokens in browser tools when possible. Treat production tokens like passwords: they may embed roles, emails, or tenant IDs. Prefer short expirations and rotate signing keys on compromise.
- Do not log full tokens in application logs.
- Reject alg=none and unexpected algorithms in production verifiers.
- Validate exp, nbf, iss, and aud on the server.