PlayInfoBox

Home /Text /JWT Structure Explained: Header, Payload, and Signature

JWT Structure Explained: Header, Payload, and Signature

A JWT looks like a scrambled string of characters, but its structure is simple once you split it into its three actual parts.

Three segments joined by dots

A JWT is header.payload.signature β€” three base64url-encoded segments separated by periods. The header describes the token type and signing algorithm, the payload carries the actual claims, and the signature verifies the first two haven't been tampered with.

It is encoded, not encrypted

Base64url encoding is reversible by anyone with no key required β€” it exists to make binary-safe data URL and JSON friendly, not to hide it. Any standard JWT header and payload can be decoded and read by pasting the token into a basic decoder.

The payload should never contain secrets

Because the payload is plainly readable by anyone who has the token, sensitive data like passwords or private personal details should never be placed in a standard JWT's claims β€” treat the payload as visible, not confidential, information.

The signature proves integrity, not confidentiality

The signature lets a server verify the token was issued by a trusted source and hasn't been altered since β€” it does not hide the payload's contents from anyone who intercepts the token. Verification requires the signing key; decoding does not.

A handful of standard claims show up constantly

exp (expiration time) and iat (issued-at time) are Unix timestamps controlling how long a token is valid; sub (subject) typically identifies the user; iss (issuer) identifies who created the token. Applications can add their own custom claims alongside these.

Why JWTs became popular for authentication

A JWT lets a server verify a request without looking up session data in a database on every call, since the token itself carries verifiable claims and an expiration. This statelessness makes JWTs convenient for distributed systems and APIs, at the cost of being harder to revoke instantly compared to a traditional server-side session.

Decoding a token and verifying it are entirely different operations

Anyone can decode a JWT's header and payload without any key at all, since it is just encoding. Verifying that a token is authentic and unmodified requires the specific signing key or public key used to create it β€” a decoded-but-unverified token should never be trusted as proof of anything.

Frequently Asked Questions

If I can read a JWT's payload without a password, is that a security flaw?

No β€” it is expected behavior by design. JWTs are meant to be readable; the security guarantee they provide is integrity (tamper-evidence) via the signature, not confidentiality of the payload contents.

Can I edit a JWT's payload and have it still work?

You can edit the decoded text, but re-encoding it without the correct signing key produces an invalid signature, so a server that properly verifies tokens will reject the modified token rather than accepting the edited claims.