JWT structure in plain English (and what decoding does not prove)

2026-11-04 · ~7 min

A JSON Web Token is three Base64url segments separated by dots: header, payload, signature. The first two are readable by anyone who has the token. Readability is intentional. Secrecy is not a property of JWTs.

Header

Typically declares the token type and algorithm (alg). Treat unexpectedalg values as hostile. Algorithm confusion bugs are old but still appear when libraries are misconfigured.

Payload

Claims such as sub, iss, aud, exp, andiat live here. Custom claims are fine; sensitive personal data is not—bearers can read them, and tokens leak into logs.

Signature

The signature binds header+payload to a key. Decoding does not verify the signature.Online “JWT debugger” pages that only Base64-decode are inspection aids. Your API must verify with the correct secret or public key, check exp/nbf, and validate issuer/audience according to your threat model.

Practical rules

• Short lifetimes + refresh strategy beat week-long access tokens for most apps.
• Do not put passwords or raw PII in claims.
• Log token ids (jti) carefully; never log full bearer tokens in production.

Inspect a sample with the JWT Decoder—and keep production tokens out of browsers that are not your own machine.