JWT Explained: Header, Payload and Signature

The three parts belong to a signed compact token

encoded-header.encoded-payload.signature

The header gives information about the token’s representation and cryptographic operation. The payload contains claims. The signature section holds the cryptographic result used to check the protected header and payload. JWS defines the signed compact representation; JWT defines the claims format and related processing.

“JWT” does not mean every token has exactly three parts. Encrypted JWTs can use a different compact structure, commonly five sections. A tool designed for a three-part signed token cannot necessarily inspect an encrypted one. Identify the representation before interpreting the output.

The header describes an operation, not a trust decision

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

Here alg names a signing algorithm, and typ is a type label. These are sample fields, not evidence that a particular real token was issued safely. A verifying application needs its own allowed algorithms and trusted key configuration. It must not treat whichever algorithm a received header requests as automatically acceptable.

Additional header fields may help a verifier select a key under an established policy. A decoder can show those fields but does not know which issuer or key your application is configured to trust. Reading a key identifier is not the same thing as securely resolving it or validating the token.

The payload is a set of claims

{
  "sub": "example-record",
  "iss": "example-issuer",
  "aud": "example-service",
  "exp": 1704067200
}

The subject claim sub identifies the subject as defined by the issuing system. The issuer claim iss identifies the issuer, while aud identifies the intended recipient or recipients. The expiration claim exp gives an expiry boundary. Applications can also define their own claims, but a readable name such as role does not make the value authoritative.

These sample claims should not be copied into a real authentication configuration. Their meaning depends on an agreement between an issuer and a recipient. Even after verifying a signature, an application needs to check that the issuer and audience are appropriate and that the claims satisfy its own rules.

Base64URL makes bytes convenient to carry as text

In the signed compact representation, the header and payload are encoded as Base64URL. That variant uses URL-friendly alphabet characters in place of the + and / characters used by ordinary Base64, and compact tokens omit padding. Encoding makes the bytes easier to transport; it does not conceal the JSON from a recipient who decodes it.

The Base64 guide explains the representation with a small text example. A generic Base64 decoder may require adaptation for the URL-safe alphabet and padding rules. An encrypted payload, by contrast, cannot simply be treated as readable JSON after ordinary Base64 decoding.

Decoding and verification answer different questions

Decoding asks what the token’s sections contain. Verification asks whether its cryptographic result matches the protected content under the expected algorithm and a trusted key. Depending on the algorithm, verification may involve a shared secret or a public key corresponding to the issuer’s private signing key. This is work for a suitable verification library and a correctly configured application.

A readable payload can be malformed, expired, meant for another service, or supplied by an untrusted source. Showing a field in a decoder does not establish any of those checks. A decoder that does not possess the relevant trust configuration cannot tell you that a token is suitable for your particular application.

Expiration claims require units and context

JWT time claims such as exp and nbf use NumericDate values measured in seconds relative to the Unix epoch. exp describes expiration; nbf describes a not-before boundary; iat records an issued-at value. They have different roles. Seeing an issued-at date does not tell you the expiry date, and a token is not necessarily valid just because exp is in the future.

The example 1704067200 corresponds to 2024-01-01 at 00:00:00 UTC. A local display can show a different clock time for the same instant. The Unix timestamp explanation covers seconds, milliseconds and time-zone display. Clock skew policies and which claims are required belong to the verifier’s configuration.

Inspect tokens without expanding their exposure

• Use a synthetic or intentionally non-sensitive sample when learning the format.
• Do not paste production bearer tokens into public discussions or unapproved debugging services.
• Keep token content out of screenshots and logs unless the handling process explicitly allows it.
• Use a maintained verification library and an explicit trust policy in the actual receiving application.

A signed token is not necessarily encrypted. Its readable claims can reveal information even when its signature is valid. If a bearer credential has been exposed, follow the system’s incident and revocation process; merely hiding the visible decoded output does not undo the exposure. JWT security best practices describe verification and algorithm safeguards in more detail.