Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsIn a compact JWT signed as a JWS, the header is the first dot-separated segment: base64url-encoded UTF-8 JSON describing the signing operation and related metadata. Decoding it lets you read those values; it does not verify the signature or make the token trustworthy. A secure consumer applies its own token-type, algorithm, and key policies, then verifies the JWS before relying on protected data.
What the JWT header represents
A JWT is a claims format that can be secured using JWS, which provides a signature or MAC, or JWE, which provides encryption. This article covers the JWS path: its JOSE Header describes the cryptographic operation and may include other processing metadata. The JWT claims themselves are in the payload, not the header. See the JWT specification, RFC 7519.
In compact JWS serialization, the token has three segments separated by periods: protected header, payload, and signature. The first segment is base64url-encoded UTF-8 JSON. Decoding it is a parsing step only; it does not establish that the token was signed by a trusted party, nor that its claims are valid.
JWS also has a JSON Serialization. It can carry a protected header and a separate unprotected header. Parameters in the protected header are included in the JWS signing input; unprotected parameters are not integrity-protected. Never use an unprotected value to make a security decision. RFC 7515 defines these formats and their processing in the JWS specification.
#1 Best Overall
Important JWS header parameters
alg: the algorithm identifier
alg identifies the algorithm used for the signature or MAC. It is mandatory in a JWS, and its value must match the cryptographic operation. RFC 7515 says of this field: “This Header Parameter MUST be present and MUST be understood and processed by implementations.”
The header is part of the token and can be attacker-controlled until verification succeeds. Therefore, do not let its alg value decide which algorithms your application accepts. Configure an allowlist for the token’s intended use, bind verification keys to their permitted algorithms, and reject mismatches. RFC 8725, the JWT Best Current Practices, warns: “Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid.” See RFC 8725.
kid: a key-selection hint
kid is an optional, case-sensitive string that helps identify the key to try, commonly by matching a kid in a trusted JWK Set. It is a hint, not proof of identity or trust. Resolve it only within the key set or issuer configuration that your application already trusts; do not treat an arbitrary value as authorization to fetch or trust a key.
typ and cty: object and content types
typ is an optional media-type hint for the complete JOSE object. JWT applications commonly use JWT. Explicit typing can help keep a valid token from being accepted in the wrong context, a practice encouraged by RFC 8725. The application should still determine which token types it accepts rather than trusting the header alone.
Rank #3
cty describes the secured content. A value of JWT can indicate that the payload is another JWT and should be processed as a nested token. Apply the expected nesting and validation rules for the application; a content-type label does not itself validate the inner token.
crit: required extension handling
crit is an optional array of header parameter names that the recipient must understand and process. Each name it lists must be present in the header; the list cannot be empty, and crit itself must be in the protected header. If a listed extension is unsupported, reject the JWS rather than ignoring it. This prevents a recipient from silently interpreting a token differently from its producer.
Key and certificate references
JWS defines parameters including jku (a URI for a JWK Set), jwk (an embedded public JWK), and certificate-related fields x5u, x5c, x5t, and x5t#S256. These identify or supply key material; their presence does not make that material trusted. Use only key discovery sources allowed by the issuer and application policy, validate certificates and identities as applicable, and ensure retrieved resources are obtained securely. RFC 7515 specifically requires integrity-protected transport and server identity validation when retrieving a jku resource.
b64: an extension for payload encoding
RFC 7797 defines b64, which controls whether the payload is base64url-encoded in the JWS representation and signing input. It defaults to true. If using the extension to leave the payload unencoded, protect the parameter and declare it critical so recipients know they must apply that processing. Do not assume every JWT library or consumer supports this non-default mode; reject it unless the implementation explicitly supports it. See RFC 7797.
Free tools Windows power users keep installed
One-click scans. No signup required.
Best Value
The IANA JOSE registry lists registered header parameter names and the JOSE structures in which they apply. JOSE includes both JWS and JWE, so a registry entry is not automatically a JWS parameter.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to process a JWS header safely
- Parse the serialization. Determine whether the input is compact JWS or JWS JSON Serialization. Decode and parse the header as valid UTF-8 JSON, and reject malformed input or duplicate parameter names.
- Establish context before trusting token metadata. Decide which token type and issuer the application expects, and whether a JWS is appropriate for this use. A successfully decoded header is not evidence of authenticity.
- Apply algorithm policy. Check
algagainst an application-configured allowlist. Ensure the selected key is permitted for that algorithm and intended use, and that the value matches the operation actually performed. - Select keys only from trusted sources. Use
kidto select among keys from an already trusted issuer or key set. Treatjku,jwk, and certificate parameters as inputs to a defined trust and validation policy, not as independent proof. - Process critical extensions. Confirm that every parameter named by
critis present and supported. Reject a token when a critical extension is unknown or cannot be correctly applied. - Verify before relying on protected content. Verify the signature or MAC over the JWS signing input, using the expected key and algorithm. Only after successful verification should the application rely on protected header values or inspect claims for the remaining JWT validation checks.
Protected versus unprotected headers: the security difference
A protected header parameter is covered by the JWS signing input, so a successful verification provides integrity for that value. An unprotected parameter in JWS JSON Serialization is outside that input and can be changed without invalidating the signature. This is why algorithm choice, critical-extension handling, and other security-relevant decisions must not depend on unprotected data.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
