JWT Structure: Header, Payload, and Signature

A JSON Web Token consists of three parts separated by periods: header.payload.signature. Each part is base64url-encoded, and together they form a compact, URL-safe string that can be transmitted in HTTP headers, query parameters, or request bodies.

Part 1: Header

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2024-01"
}

The header (also called the JOSE header) declares the token type and the signing algorithm. The alg field is required and specifies which algorithm was used to create the signature (e.g., HS256, RS256, ES256). The typ field is conventionally set to "JWT". The kid (key ID) field helps the verifier select the correct key from a key set. The header is base64url-encoded but not encrypted, so its contents are readable by anyone.

Part 2: Payload

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1700000000,
  "exp": 1700003600,
  "roles": ["admin", "editor"]
}

The payload contains the claims: statements about the entity (typically the user) and additional metadata. Claims are categorized as registered (defined by RFC 7519, like sub, exp, iss), public (registered in the IANA JSON Web Token Claims registry), and private (custom claims agreed upon by the issuing and consuming parties). Like the header, the payload is base64url-encoded, not encrypted. Never store sensitive data like passwords or credit card numbers in the payload.

Part 3: Signature

The signature is computed over the encoded header and payload using the algorithm specified in the header. For HS256: HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). The signature ensures that the header and payload have not been tampered with. Changing a single character in either the header or payload invalidates the signature.

The complete token:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.signature

This compact format is why JWTs are popular for HTTP authentication: they fit in an Authorization header and carry their own integrity proof.