x5c (X.509 Certificate Chain) Header Parameter

The encoding is the detail that catches people. Almost everything in a JOSE structure is Base64URL, but RFC 7515 specifies standard Base64 for the certificates in x5c, so the strings can contain plus and slash characters and carry equals padding. Decoding them with a Base64URL decoder either fails or produces corrupt DER, and the resulting error rarely points at the encoding.

Embedding the chain removes the network fetch that x5u needs, which removes the request forgery risk with it, but it does not change the trust question. A certificate in the header was put there by whoever made the token. It is only evidence once the chain has been validated to a trust anchor you configured, with expiry, revocation and key usage checked, and the subject or a pinned thumbprint compared against the issuer you expected.

Size is a practical cost. A single certificate is often one to two kilobytes before encoding, and a chain of three pushes the header past the size of most payloads. Tokens travel on every request, and some proxies cap header size, so a token that works in testing can fail at a gateway once the chain grows by one intermediate.

The decoder shows x5c as the decoded JSON array, so you can see how many certificates the issuer embedded and how large the header has become. It does not parse the certificates or extract a key from them: to verify the signature you paste the PEM public key, which for a certificate means extracting the key from it first.