JWT Signature Verifier

About the JWT Signature Verifier

Decoding a JWT shows what it claims; verifying it shows whether to believe it. Paste a token and the key you trust — a shared secret for HS256, the issuer’s PEM public key or certificate, a JWK, or the issuer’s JWK Set (the key is chosen by the token’s kid) — and the page checks the signature with your browser’s Web Crypto, then everything a careful relying party checks: an algorithm allow-list, alg: none, algorithm confusion (an HS token checked with a public key), secrets shorter than RFC 7518 §3.2 allows, exp, nbf and iat with clock skew, the issuer, the audience and the type.

Every check comes with the rule behind it — RFC 7519, RFC 7515, RFC 7518 and the JWT Best Current Practices of RFC 8725 — and the risky header parameters are named: jku and x5u URLs, an embedded jwk, unknown crit entries and a kid that looks like a path or SQL. HS256, HS384, HS512, RS256–RS512, PS256–PS512, ES256–ES512 and EdDSA (Ed25519) are supported. Nothing is uploaded: the token, the secret and the keys stay in your browser.

Without a pass you see a free preview: the verdict, every count and the token’s header and claims, with the first checks of the report. The whole report, and copying or downloading it, unlock with a Pro pass.

Common uses

• Debugging "invalid signature" or "jwt expired" errors between an identity provider and your API.
• Checking that your own token issuer sets the algorithm, kid, issuer, audience, type and expiry that verifiers expect.
• Testing a JWT library or gateway configuration against the RFC 8725 attacks (alg none, algorithm confusion, weak secrets, jku).
• Seeing which key in a JWKS a token was signed with, and spotting a key rotation the verifier has not picked up.

What a careful verifier checks

• The algorithm: accept only the algorithms you expect for your key, never whatever the header says (RFC 8725 §3.1); reject none (RFC 8725 §3.2, RFC 7518 §3.6).
• The key: the issuer’s key, chosen by kid from its JWK Set, of the right type for the algorithm and not marked for another algorithm or for encryption (RFC 7517 §4.2–4.4).
• The signature over the first two parts, exactly as sent (RFC 7515 §5.2).
• Time: exp in the future and nbf in the past, allowing a small clock skew; iat not in the future (RFC 7519 §4.1.4–4.1.6).
• Who: iss is the issuer you expect and the key belongs to it (RFC 8725 §3.8); aud names your service (RFC 8725 §3.9).
• What kind: an explicit typ such as at+jwt keeps an ID token from being used as an access token (RFC 8725 §3.11, RFC 9068).

Attacks the checks catch

• alg: none — an unsigned token that a careless library accepts.
• Algorithm confusion — a token switched from RS256 to HS256 and signed with the server’s public key as the HMAC secret; a verifier that takes the algorithm from the token accepts it (RFC 8725 §2.1).
• Weak secrets — HS256 needs at least 256 bits (RFC 7518 §3.2); a word or a short password can be guessed offline from a single token, and RFC 8725 §3.5 forbids human-memorable passwords as HMAC keys.
• Keys from the token — jku, x5u, jwk and x5c let a token point to or carry its own key; following them blindly lets an attacker supply the key (RFC 8725 §3.10).
• kid injection — a kid such as ../../dev/null or one with SQL in it attacks key lookups that trust it (RFC 8725 §3.10).
• Unknown crit — a token that marks a header parameter as critical must be rejected when the verifier does not understand it (RFC 7515 §4.1.11).

When a valid-looking token fails

• Invalid signature with HS256: the secret is often meant as Base64 (its decoded bytes) while you typed it as text, or the other way round — the page tries both and says which matches — or a line break was copied with it.
• Invalid signature with RS256/ES256: the issuer rotated its keys and the kid points to a new one; fetch its JWK Set again. An ES256 signature of about 70 bytes is DER, which JWS does not allow (RFC 7518 §3.4 requires 64 raw bytes).
• Expired, not valid yet or issued in the future: compare the device clocks; a minute or two of skew is normal.
• Wrong audience or issuer: they are compared exactly, so https://login.example.com and https://login.example.com/ differ.

Limitations

• Signed tokens only (JWS compact form): encrypted JWE tokens are recognised but not decrypted. Detached and JSON-serialized JWS are not read.
• ES256K (secp256k1) and Ed448 cannot be checked in browsers; EdDSA needs Ed25519 support in Web Crypto (current browsers).
• The page never fetches keys: paste the JWK Set from the issuer’s jwks_uri yourself. It checks the key you give, not whether that key really belongs to the issuer.
• Times are checked against your device clock unless you choose another time; nested JWTs (cty "JWT") are pointed out, not opened.

Privacy

On this device: nothing is sent

Your token, secret and keys are checked only in this tab with your browser’s Web Crypto: nothing is uploaded, logged or stored. Treat live tokens and secrets as passwords anyway — they work until they expire.