JWT Structure

Three segments, two dots

The compact serialization is header.payload.signature — each segment independently Base64url-encoded, the dots as literal separators. The encoding is deliberately unpadded, so a token contains only letters, digits, hyphens and underscores: safe in URLs, headers and cookies without escaping. Decoding the first two segments is not a hack — it is the intended way to inspect a token; the third segment is where verification happens.

A real token, with a signature computed over it, decodes exactly like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzg0OTIiLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJpYXQiOjE3NjcyMjU2MDAsImV4cCI6MTc2NzMxMjAwMCwianRpIjoiYjBmNmMyZDQtNGU3YS00YzFmLTlhMmItM2Q1ZTdmOWExYzNlIn0.iDPqw4BRxZtM064Y3EH83XLB0cgEjbj5snSXeM846VY

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

{"iss":"https://auth.example.com","sub":"user_8492",
 "aud":"api.example.com","iat":1767225600,
 "exp":1767312000,
 "jti":"b0f6c2d4-4e7a-4c1f-9a2b-3d5e7f9a1c3e"}

The header: the token's table of contents

The header is a small JSON object — formally the JWS Protected Header. Two fields do almost all the work: alg names the signing algorithm, and typ records the media type, conventionally JWT. A third, kid (key ID), points the verifier at the right key when an issuer publishes several. The header is signed but never encrypted, and it is trusted only after the signature verifies — until then, alg is a claim, not a fact.

The payload: registered claims and what each promises

The payload is a JSON object of claims. Seven are registered by RFC 7519 with precise, interoperable meanings; everything else is private to the issuer and the audience. Times are NumericDate values — seconds since the Unix epoch, not milliseconds — and the time claims are advisory to the verifier: checking them is the verifier's job, not something the format enforces.

The signature: HS256, RS256 and how verification works

The signature is computed over the signing input — the encoded header, a dot, the encoded payload — using the algorithm the header names. HS256 is HMAC-SHA256 with a shared secret: fast and symmetric, appropriate only when the signer and every verifier form one trust domain, because anyone holding the secret can mint tokens. RS256 is RSA: the issuer signs with a private key and anyone — including a browser — can verify with the published public key, which is what makes it the default for federated protocols like OAuth 2.0 and OpenID Connect.

Verification recomputes the signature and compares. That is the entire mechanism — and it is why the alg header alone decides how the check runs. Libraries hardened themselves after the algorithm-confusion attacks of the early 2010s: a token claiming alg none, or an RS256 token replayed as HS256 using the public key as the HMAC secret, verifies only against verifiers that fail to pin their expected algorithm.

HS256: HMAC-SHA256(secret, header + '.' + payload)
       signer and verifier share the secret

RS256: RSA-SHA256(private key, header + '.' + payload)
       issuer signs; anyone verifies with the public key

Pin the expected algorithm per issuer.
Never derive it solely from the token's own header.
Never accept alg: none.

Signed, not sealed: what the signature does not do

The signature proves the token was issued by whoever holds the key and has not been altered since — integrity and authenticity. It provides zero confidentiality: Base64url is an encoding, and the payload is readable by anyone who sees the token, including browser extensions, proxies when tokens travel in URLs, and log collectors. The standing rules follow: never put secrets in a JWT payload, never send tokens in URLs, and treat every decoded claim as data rather than as a decision.

That last point is the client-side trap. A browser can decode a token and read exp or sub — but it cannot meaningfully verify the token, because it does not hold the issuer's key: with HS256 the secret must never reach the browser at all, and with RS256 a client-side check proves nothing about what the holder may access. Clients may inspect tokens for presentation — showing a name, warning about expiry — but the server must verify the signature and every claim on every request. Inspection is not verification, and readable is not authorised.

Inspecting tokens safely — the practical loop

A disciplined inspection loop takes seconds: decode the header and payload, check exp and nbf against the clock, confirm iss and aud are what you expect, and only then — on the server — verify the signature with a pinned algorithm and the right key. Everything except the final verification is pure text processing, which is why a decoder that runs entirely in your browser is the right tool: real tokens are bearer credentials, and credentials belong in tabs you control, not in websites that might forward them.

Remember what the structure cannot give you: revocation — jti-based blocklists must be built and checked server-side; confidentiality — use JWE if you need encrypted tokens; and trust — a structurally perfect token from an issuer you never configured is worthless. The structure tells you what was promised; only verification tells you the promise is intact.