x5t (X.509 Certificate SHA-1 Thumbprint) Header

The value is computed over the DER encoding of the whole certificate, not over the public key inside it, and the result is base64url encoded without padding. Twenty bytes of digest give twenty seven characters, which is a quick way to tell x5t from x5t#S256 at a glance: the SHA-256 variant is forty three characters.

Its job is selection, not verification. The verifier holds a set of certificates it already trusts, computes or stores their thumbprints, and uses the header value to pick one. Nothing about the token is proved by the thumbprint matching, exactly as nothing is proved by kid matching; the proof comes afterwards from checking the signature with the key in that certificate.

SHA-1 is broken for collision resistance, and the usual conclusion does not quite transfer here. Producing a second certificate with the same thumbprint requires a preimage attack, which SHA-1 still resists, and a colliding pair would both have to be certificates the verifier trusts. The reason to prefer x5t#S256 is that its security margin is not something anyone has to reason about carefully.

In the decoder x5t appears as a plain string in the header JSON. The tool does not hold certificates and does not resolve thumbprints, so the value is informational here: verification still means pasting the PEM public key. Comparing the value against a certificate you have is a small manual step, and one worth taking when a verifier is picking the wrong certificate.