Quick answerLearn the three parts of a JWT token, how Base64url encoding works, what header and payload claims mean, and why decoding does not verify a signature.

What are the three parts of a JWT token?

A typical signed compact JSON Web Token (JWT) has three segments separated by periods:

COMPACT SERIALIZATION3 SEGMENTS
BASE64URL(header).BASE64URL(payload).BASE64URL(signature)

The first segment is the protected header. The second is the claims payload. The last segment contains the cryptographic signature or message authentication code for a signed token. The periods are structural separators, not part of any individual segment.

This is the common compact representation of a signed JWT (a JWS). Encrypted compact JWTs (JWE) have a different five-part structure, so a three-part decoder should explain that distinction instead of treating every token as the same format.

The header is JSON describing the protected token metadata. Common members include alg, which identifies the cryptographic algorithm used for signing, and typ, which can indicate that the object is a JWT. Some systems include kid, a key identifier used by a verifier to select a key from a trusted set.

HEADER EXAMPLEJSON
{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "key-2026-01"
}

These values are data from the token, not a source of trust. A verifier must apply an allowed algorithm policy and resolve keys through trusted configuration. It must not accept an algorithm just because the incoming header asks for it.

Part 2: the JWT payload

The payload contains claims: statements represented as name/value pairs. Registered claims include issuer, subject, audience and time-related values. Applications can also use public or private claim names for domain-specific information. Registered claims are not automatically mandatory in every JWT; the application defines which claims are required and how they are interpreted.

PAYLOAD EXAMPLEJSON
{
  "iss": "https://identity.example.test",
  "sub": "user-42",
  "aud": "orders-api",
  "iat": 1767225600,
  "exp": 1893456000,
  "role": "reader"
}

Because Base64url is an encoding, not encryption, do not place secrets or data that must remain confidential in an ordinary signed JWT payload. Anyone who gets the token may be able to read the claims. Use a different architecture or an encrypted token format when confidentiality is required.

Part 3: the signature segment

The signature protects the encoded header and payload against undetected modification when it is correctly generated and verified. For an HMAC algorithm, the signature uses a shared secret; for an asymmetric algorithm, the issuer signs with a private key and the verifier checks with a corresponding public key.

A formatter can show the signature segment, but that is not the same as checking it. Verification needs a trusted key, a configured algorithm allowlist and the application's validation policy. It is also common to validate issuer, audience, expiry and authorization conditions after signature verification.

The distinction to rememberA token that decodes successfully can still be expired, tampered with, meant for a different audience or invalid under your application's policy.

What Base64url means in a JWT

JWT compact serialization uses Base64url encoding for the JSON header and payload. Compared with standard Base64, Base64url uses hyphen (-) and underscore (_) where standard Base64 uses plus and slash. Padding is commonly omitted in compact serialization. The encoded text is designed to travel safely in URLs and HTTP contexts.

Decoding reverses the encoding to reveal the JSON bytes. It does not decrypt the value, verify a signature or establish the identity of the issuer. A useful formatter should therefore display the decoded JSON while clearly stating what remains unchecked.

Common JWT structure errors

  • Two or four segments: a dot may be missing or the value may not be a standard three-part compact JWS.
  • Five segments: it may be a compact JWE, which needs decryption and appropriate keys instead of a simple payload decoder.
  • Base64url failure: the value may be truncated, copied with invalid characters, or changed by an application that wrapped the token.
  • JSON parse failure: a segment can decode to text that is not a JSON object.
  • Unexpected claim: the claim may be application-specific or optional. Check the issuing system and the protocol you are using.

Paste a test token into the DevArea JWT inspector to see each segment separately. For claim meanings, continue to the JWT fields reference.

References and further reading

Primary standards and documentation used to support this guide.

Frequently asked questions

Can a JWT have only two parts?

A signed compact JWS JWT normally has three dot-separated segments. Some unsecured JWT representations can have an empty signature segment, but they still have two periods. A two-segment value is not the usual compact serialization.

Are JWT payloads encrypted?

Not by default. A signed JWT payload is Base64url-encoded, not encrypted. Anyone who obtains the token can generally decode its claims.

Does decoding all three parts prove a token is valid?

No. Decoding reveals data. A verifier must check the signature with trusted key material and validate the claims and policies expected by the application.

What is the difference between JWT and JWE?

JWT is the claims format. JWS is commonly used for signed compact JWTs with three segments. JWE is used for encrypted content and its compact serialization generally contains five segments.

Keep learning

Put the explanation to work.

Inspect a token in the browser-based JWT formatter, then use the claims reference when you need to understand a field.

Open JWT inspector