JWT Header Analyzer

Runs in browser Security

Explains every header parameter of a JWT and flags dangerous values such as alg=none, jku/x5u URLs and unexpected key ids that are frequently abused in token attacks.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What is a JWT?

A JSON Web Token is a compact string of three Base64url segments — header.payload.signature — that carries claims about a user or client (subject, roles, expiry) together with a signature the receiver can verify. Defined in RFC 7519 with its signing rules in RFC 7515 and 7518, it is the usual format for OAuth 2.0 access tokens and OpenID Connect ID tokens. The payload is only encoded, not encrypted: anyone holding the token can read it.

Security note: Decoding is not verifying. A server must check the signature with a pinned algorithm, reject alg=none, and validate exp, iss and aud — and a real token pasted anywhere is a secret until it expires.

Read the guide: What is a JWT? JSON Web Tokens Explained

How to use JWT Header Analyzer

  1. Paste a JWT, or only its header segment / header JSON.
  2. Check the summary for algorithm, key type and remote key references.
  3. 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 risks described in RFC 8725: unsecured JWS (alg none), algorithm substitution (for example RS256 changed to HS256), jku/x5u URLs that a verifier follows blindly (server-side request forgery), and kid values used unsanitised in SQL or LDAP lookups. The tool also flags an embedded jwk and path-like kid values, two further ways a careless verifier can be steered to an attacker's key; these checks are heuristics, not RFC 8725 requirements. A secure verifier ignores the header's suggestions about keys and algorithms and uses its own configuration instead.

References