How to use JWT Header Analyzer
- Paste a JWT, or only its header segment / header JSON.
- Check the summary for algorithm, key type and remote key references.
- Review the risk analysis and make sure your verifier rejects the flagged patterns.
JWT Header Analyzer features
- Explains every JOSE header parameter: alg, typ, cty, kid, jku, jwk, x5u, x5c, x5t, crit, enc, zip
- Describes the algorithm family and key type (shared secret vs public key)
- Flags alg=none, empty signatures, remote key URLs, embedded keys and injection-like kid values
- Accepts a full token, just the first segment, or the header as JSON
- Overall risk level with prioritised findings
JWT Header Analyzer example
A header with a JWK Set URL
Input:
{"alg":"RS256","typ":"JWT","kid":"2026-03-key-1","jku":"https://auth.example.com/.well-known/jwks.json"}Output:
High — jku (JWK Set URL) present: verifiers must only accept allow-listed hosts.
OK — RS256 (RSA public key): pin the expected algorithm to avoid HS/RS confusion.
Info — kid = 2026-03-key-1: use only to select pre-configured keys.Frequently asked questions about JWT Header Analyzer
What is the "alg=none" attack?
Some early libraries accepted tokens whose header declared alg "none" and skipped signature verification entirely, letting attackers forge any payload. Verifiers must reject "none" and only accept an explicit allow-list of algorithms.
What is algorithm confusion (HS/RS)?
If a verifier trusts the alg from the header, an attacker can change RS256 to HS256 and sign the token with the server's public key (which is public) as the HMAC secret. Always pin the expected algorithm on the server side.
Why are jku, x5u and jwk headers flagged?
They tell the verifier where to fetch — or directly embed — the key used to check the signature. If a verifier follows them blindly, an attacker can supply their own key. Only keys from a pre-configured store should be trusted.
What should kid contain?
An opaque identifier used to look up one of the issuer's published keys. Values with path separators, quotes or SQL fragments indicate injection attempts against verifiers that use kid to load files or database rows.
Technical notes
Header findings are based on RFC 7515/7516/7518 and the attacks catalogued in RFC 8725: unsecured JWS (alg none), algorithm substitution, key-source injection through jku/x5u/jwk, and kid used as a file path or SQL fragment. A secure verifier ignores the header's suggestions about keys and algorithms and uses its own configuration instead.