skip to content

What are the three dot-separated parts of a JWT, and what does each contain?

level: juniorimportance: must knowfreq 88%

answer

  1. Two dots, three segments
  2. Metadata, data, proof
  3. The first two are just JSON
  4. Header names the algorithm and key
  5. Signature covers segments one and two

basics

~10 s

A signed JWT is three Base64url segments joined by dots: a JOSE header naming the algorithm and key, a JSON claims payload, and a signature computed over the first two segments.

solid answer

~40 s

The compact serialization of a signed JWT is `header.payload.signature` — three Base64url segments separated by ASCII dots. The **header** is a small JSON object (the JOSE header) carrying at least `alg`, usually `typ`, and often `kid` to identify the key. The **payload** is the claims set: a JSON object whose members are claims such as `iss`, `sub` and `exp`, plus any application claims the issuer adds. The **signature** is the raw signature or MAC bytes over the first two encoded segments, itself Base64url-encoded. Splitting on the dot is unambiguous because the dot is not in the Base64url alphabet, so a parser can slice the token before decoding anything. Only the third segment needs a key to produce; the first two are plain JSON that anyone holding the token can decode.

code

text · 5 lines
text
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjIwMjYtMDUifQ   <- header
.
eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyLTQyIn0   <- payload
.
<Base64url of the raw signature bytes>   <- signature

go deeper

for a junior

Be ready to name the three segments in order and say what each holds, and to state that the first two are Base64url-encoded JSON you can read with any tool.

for a middle

Explain why the dot is a safe separator, that the header is covered by the signature, and that decoding a token is not the same operation as verifying it.

for a senior

Show you treat a received token as an opaque string in production code, and that you can spot a five-segment JWE or a suspicious segment count while debugging an auth failure.

for a principal

Own the question of what belongs in a token at all: the format invites teams to ship state in the payload, and the shape of segment two drives header size, log exposure and coupling between services.

## What a JWT is A JWT (JSON Web Token) packages a set of JSON name/value pairs — *claims* — into a compact, URL-safe string that a recipient can verify came from the expected issuer and has not been altered. In its overwhelmingly common form a JWT is a **JWS** (JSON Web Signature) in *compact serialization*, and that is the three-part shape people mean when they say "JWT". ## The compact serialization The token is the Base64url encoding of the header JSON, a dot, the Base64url encoding of the payload, a dot, and the Base64url encoding of the signature bytes. Three segments, two ASCII dots. The dot is a deliberate choice: it does not appear in the Base64url alphabet, so `token.split('.')` is a safe, decode-free way to reach any segment. That is why a JWT can be handed to a logging pipeline, a URL or an `Authorization: Bearer` header and still be sliced apart reliably. ## Segment 1 — the JOSE header A JSON object describing how the token was protected. `alg` is required and names the signing algorithm. `typ` conventionally carries the media type (`"JWT"`, or an application-specific type). `kid` is a hint telling the verifier which key to use when the issuer holds more than one. The header is metadata about the cryptography, never a place for application data — and it is *not* a free-for-all: it is covered by the signature, so an attacker cannot edit it without breaking verification. ## Segment 2 — the claims payload A JSON object whose members are claims. Some are *registered* by the JWT specification with defined meanings (`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, `jti`); the rest are chosen by the issuer. Every registered claim is optional as far as the format is concerned — the format defines the vocabulary, the application decides which claims it demands. Nothing about this segment is confidential: it is encoded, not encrypted. ## Segment 3 — the signature The output of running the signing algorithm named in `alg` over the *encoded* first two segments, then Base64url-encoding the resulting bytes. With a symmetric algorithm this is a MAC produced with a shared secret; with an asymmetric one it is a signature produced with a private key and checked with a public key. Because the signature covers the header too, the declared algorithm and key id are themselves protected. Its length is fixed by the algorithm, not by the payload size — a bigger claims set does not produce a longer signature. ## Decoding it Decoding is not verification. Any tool — a shell one-liner, a debugger, a browser console — can split the string and Base64url-decode segments one and two to reveal the JSON. Producing a *valid third segment* is what requires a key. A candidate who says "I decoded the token, so it must be genuine" has confused reading with verifying. ## The five-part cousin It is worth knowing that not every JOSE token has three parts. An encrypted token — a JWE — in compact serialization has **five** dot-separated segments: protected header, encrypted key, initialization vector, ciphertext and authentication tag. So segment count is itself a quick tell for which shape you are holding. ## What interviewers listen for Three things: that you name the segments in order and say what each is *for*; that you know the first two are JSON and readable; and that you can state where the signature's input comes from. It is a warm-up question, but a fuzzy answer here predicts fuzzy answers about validation later.

  • Does splitting a JWT on the dot ever risk cutting into a segment?
    No. Base64url's alphabet is A–Z, a–z, 0–9, '-' and '_', and JOSE drops the '=' padding, so the dot cannot occur inside a segment. That is exactly why the dot was chosen as the separator, and why a parser can slice a token without decoding it first.
  • How many segments does an encrypted token in compact form have?
    Five: protected header, encrypted key, initialization vector, ciphertext and authentication tag, each Base64url-encoded and dot-separated. So a token with four dots is a JWE, not the three-part signed JWS people usually mean by "JWT".
  • Does the signature segment grow with the size of the claims payload?
    No. Its length is determined by the algorithm — an HMAC-SHA-256 tag is 32 bytes and an RSA signature is the key's modulus size — regardless of how large the payload is. A token that grows is growing in its second segment.

Think of a sealed exam envelope with a transparent window: anyone can read the name and date through the window (header and payload), but only the invigilator's stamp across the flap (the signature) tells you nobody swapped the contents.

saying these in an interview costs you the question

  • Says the payload is encrypted and unreadable
  • Cannot say which segment holds alg
  • Thinks successfully decoding a token proves it is genuine
  • Claims the signature covers only the payload
  • Believes every JOSE token has exactly three parts

context

resolving links…