x5t#S256 (X.509 SHA-256 Thumbprint) Header

The computation matches x5t with SHA-256 in place of SHA-1: take the DER encoding of the complete certificate, hash it, base64url encode the digest without padding. Thirty two bytes give forty three characters. The parameter name genuinely contains a hash character, which is legal in a JSON member name and is a nuisance in code that assumes member names are simple identifiers.

As a header parameter its role is selection, the same as x5t: pick the right certificate from a set the verifier already trusts, then verify with the key inside it. Because the digest is computed over the certificate rather than over the key, reissuing a certificate for the same key changes the thumbprint, which is a real operational detail when certificates renew more often than keys do.

The same value shape turns up in a different place. RFC 8705 binds an access token to the client certificate used on a mutually authenticated connection by putting an x5t#S256 member inside the cnf claim of the token payload. That is a payload claim about the presenter's certificate, not a header parameter about the signer's, and mixing the two up when reading a token leads to a lot of confusion.

The decoder shows the parameter in the header JSON with the hash character intact, and a cnf claim with an x5t#S256 member under Custom claims, so both are visible when both are present. Neither is resolved against anything: verification uses the PEM public key you paste, and the certificate binding is checked by the resource server on the live connection, not here.