JWT Header typ Field

Understand the JWT header typ (type) field, why it is set to JWT, when to use different type values, and how the typ field helps with token disambiguation.

Concept

Detailed Explanation

The typ (type) parameter in the JWT header declares the media type of the complete token. For standard JWTs, this value is conventionally set to "JWT". While it may seem like a trivial field, it plays an important role in environments where multiple token types coexist and need to be disambiguated.

Standard usage:

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

The typ field is technically optional per RFC 7519, and most JWT libraries do not require it to be present. However, including it is recommended because it helps middleware, logging systems, and debugging tools quickly identify the token format without parsing the payload.

The typ value for JWTs:

RFC 7519 specifies that when present, the typ value should be "JWT" (case-insensitive per RFC 7515, but conventionally uppercase). The "application/" prefix is omitted by convention: instead of "application/jwt", the compact form "JWT" is used. This is consistent with the JOSE (JSON Object Signing and Encryption) specification's handling of media types.

Disambiguating token types:

In systems that use multiple JOSE-based token formats, the typ field becomes essential. For example, OAuth 2.0 DPoP (Demonstrating Proof-of-Possession) uses "dpop+jwt" to distinguish DPoP proof tokens from regular access tokens. The Security Event Token (SET) specification uses "secevent+jwt". OpenID Connect's Logout Token uses "logout+jwt". Without the typ field, a server receiving one of these tokens might incorrectly process it as a standard JWT.

Validation considerations:

When your application only accepts standard JWTs, validate that typ is either absent or set to "JWT". This prevents type confusion attacks where a DPoP proof or other specialized token is submitted in place of an access token. Some JWT libraries support this check as a configuration option. In environments where you process multiple token types, use typ as the first dispatch point to route the token to the appropriate validation logic.

Relationship with cty:

The cty (content type) header parameter describes the payload's media type and is used in nested JWTs (a JWT inside a JWE). When a JWT payload itself contains another JWT, the outer token's header should include "cty": "JWT" to indicate that the payload should be processed as a JWT after decryption. This is distinct from typ, which describes the overall token.

Use Case

An OAuth 2.0 authorization server uses the typ field to distinguish between regular access tokens (typ: JWT) and DPoP proof tokens (typ: dpop+jwt) during validation.

Try It — JWT Decoder

Open full tool