typ (Type) Header Parameter in a JWT

The value is a media type with the application/ prefix left off by convention, so JWT rather than application/JWT. RFC 7515 makes it optional and says it is intended for use by the application rather than by the JOSE layer, which is why so many tokens carry the uninformative value JWT and nothing more specific.

Cross token confusion is what a specific value prevents. An authorization server signs several different documents with the same key: ID tokens, access tokens, logout tokens, and possibly software statements. If none of them say what they are, a resource server that only checks the signature and the claims can be handed a logout token and find enough familiar claims in it to proceed.

RFC 9068 fixes that for access tokens by requiring the value at+jwt, and instructing resource servers to reject anything else. DPoP proofs use dpop+jwt for the same reason. The pattern generalizes: give each kind of token its own type, check it explicitly, and one signing key stops being a way to substitute one document for another.

The decoder shows typ in the header JSON exactly as it was encoded and adds an informational line to its validation list when the parameter is missing, since its absence is worth noticing rather than an error in itself. It does not know which type your application expects, so the comparison against at+jwt or anything else stays in your own verification code.