cty (Content Type) Header Parameter in a JWT
cty declares the media type of the payload inside the token. Its one common use is the value JWT, which says the payload is itself a complete token rather than a JSON claims set.
At a glance
- Parameter
- cty (Content Type)
- Defined in
- RFC 7515 section 4.1.10
- Value type
- String, a media type with the application/ prefix conventionally omitted
- Required
- Optional, and RFC 7515 recommends omitting it unless the payload is not a plain claims set.
- Common value
- JWT, meaning the payload is a nested token
- In the decoder
- Shown in the header JSON. The payload of a nested token appears as an encoded string, which can be pasted back in to decode the inner token.
In detail
typ describes the whole token; cty describes what is inside it. For an ordinary JWT the payload is a JSON claims set, that is the default assumption, and RFC 7515 says to leave cty out rather than state the obvious. The parameter earns its place when the payload is something else, and in JOSE that almost always means another token.
Nesting has two real uses. Signing a token and then encrypting the result gives confidentiality for claims that should not be readable in transit, and the outer header carries cty of JWT so the recipient knows to process the plaintext as a token rather than as claims. Countersigning works the same way, where one party signs a token another party already signed.
Order matters when you build one. Sign first and then encrypt, so the signature covers the real claims and the encryption covers the signature. Encrypting first and signing the ciphertext proves only that somebody signed an opaque blob, and it lets the outer signer be swapped without touching the inner content, which is rarely what anyone intends.
In the decoder a nested token shows its outer header, with cty visible, and a payload that is an encoded string rather than a claims object. There is no automatic unwrapping, and copying the inner token back into the input box decodes it as a token in its own right. Encrypted tokens are a different structure with five parts, which this decoder does not process.
Examples
// Outer: says the payload is itself a token
{ "alg": "RS256", "cty": "JWT", "typ": "JWT" }
// Inner token, carried as the payload
{ "alg": "ES256", "typ": "JWT" }
{ "iss": "https://auth.example.com", "sub": "8f14e45fceea167a5a36dedd4bea2543" }Things that catch people out
- Setting cty to JWT on an ordinary token. It tells recipients to look for a nested token that is not there.
- Encrypting first and signing the ciphertext. Sign the claims, then encrypt, so the signature actually covers what it appears to cover.
- Forgetting that nesting doubles the size. Each layer adds its own header and signature, and tokens travel on every request.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →typ (Type) Header Parameter in a JWT
The typ header declares the media type of a token. Why at+jwt exists, how typ prevents cross token confusion, and what the decoder flags.
alg (Algorithm) Header Parameter in a JWT
The alg header names the algorithm used to sign a JWT. Why the accepted algorithms belong in configuration, and what the decoder does with the value.
crit (Critical) Header Parameter in a JWT
The crit header lists extension parameters a verifier must understand or reject. The rules on what may appear in it, and why it fails closed by design.
kid (Key ID) Header Parameter in a JWT
The kid header says which key signed a token. How rotation depends on it, why the value must be a lookup and never a path, and decoder behaviour.
jku (JWK Set URL) Header Parameter in a JWT
The jku header points at a JWK Set URL for the signing key. Why following it blindly gives an attacker both forgery and SSRF, and safe handling.
jwk (JSON Web Key) Header Parameter in a JWT
The jwk header embeds the public key in the token itself. Why trusting it verifies nothing, where it is legitimate, and how the decoder treats it.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server