JWT Structure: Header, Payload and Signature

A compact signed JWT has three dot-separated segments

The common signed form is a JWS Compact Serialization. It contains a protected header, a payload and a signature. An encrypted JWE compact token has five segments instead, so segment count is useful context rather than proof that a token is valid.

base64url(header).base64url(payload).base64url(signature)

Header: algorithm and token metadata

The JOSE header is a JSON object. alg identifies the declared signing or MAC algorithm, while typ is commonly JWT. A verifier must enforce its own algorithm policy instead of trusting the header to choose any algorithm.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload: registered and application claims

The payload carries claims such as sub, iss, aud, exp and application-specific values. In a signed JWT the payload is encoded, not encrypted, so anyone who receives the token can usually read it.

{
  "sub": "1234567890",
  "name": "Ada Lovelace",
  "admin": true
}

Signature: integrity over the encoded header and payload

For compact JWS, the signing input is the exact Base64URL header, a dot, and the exact Base64URL payload. The resulting signature or MAC is encoded as the third segment. Any protected-byte change should make verification fail.

sign(
  base64url(header) + "." + base64url(payload),
  trustedKey
)

Base64URL makes segments URL-safe; it does not encrypt them

JWT compact serialization uses the URL-safe Base64 alphabet and normally omits trailing padding. Converting a segment back to JSON reveals its contents but supplies no authenticity, authorization or confidentiality guarantee.

Three segments usually mean JWS; five segments mean JWE

Safe inspection workflow

• Decode only tokens you are authorized to inspect.
• Treat decoded claims as untrusted until verification succeeds.
• Never paste production bearer tokens into third-party services.
• Validate issuer, audience and time claims after the signature.