What Is a JWT?

Anatomy of a JWT

A JWT has three parts separated by dots: a header, a payload, and a signature. The header names the signing algorithm and, usually, the identifier of the key that signed the token. The payload carries the claims — the actual statements the token is making. The signature is what lets a recipient confirm that the header and payload have not been altered since the issuer created them.

header.payload.signature

It is important to understand that the first two parts are merely base64url-encoded JSON, not encrypted in any way. Anyone who holds the token can decode and read them with no key at all. Their integrity, not their secrecy, is what the signature protects, and that distinction shapes everything you should and should not put inside a token.

Claims

Claims are the individual statements inside the payload. Registered claims have standardised meanings agreed across the ecosystem — issuer, subject, audience, and expiry are among the most important — while custom claims carry application-specific data such as roles, permissions, or a tenant identifier.

When the Merion API issues a token, these claims describe who or what the token represents and the precise boundaries of its validity. The registered claims are not decoration: the expiry claim says when the token stops being valid, and the audience claim says which service it was meant for. Both are load-bearing security checks that a recipient must enforce, not optional metadata to glance at. Reading the claims tells you what a token asserts; only verification tells you whether those assertions can be trusted.

Why signatures matter

The signature is computed over the header and payload using either a shared secret or the issuer's private key, depending on the algorithm. If even a single character of the header or payload changes, the recomputed signature no longer matches and verification fails immediately. This is what lets a resource server trust a token's contents without contacting the issuer on every single request.

That self-contained, locally verifiable property is the JWT's defining advantage over an opaque token that would require a network call to validate. It is also what makes JWTs scale so well across many services. But the guarantee only holds if you actually perform the verification correctly, with the right key and the right algorithm — see Validating a JWT for the full set of checks that make the signature meaningful.

What a JWT is not

A standard JWT is not encrypted, so you must never place secrets such as passwords, full payment details, or other sensitive data in its payload, where anyone holding the token can read them. It is also not automatically trustworthy: a token is only as good as the verification a recipient performs on it, and an unverified JWT is simply untrusted text that happens to be well formatted.

Finally, because the contents are self-contained and signed, you cannot quietly change a token's data after issuing it without breaking the signature; updates mean issuing a new token. These limits are not weaknesses so much as the natural shape of the tool. To understand how the keys behind the signature are published and replaced over time, read JWKS and Key Rotation.