JWT Verifier

Decoding a JWT tells you what it claims. Verifying tells you whether you can believe it — by recomputing the signature and checking it matches. The two operations use different keys depending on the algorithm in the header: HMAC algorithms (HS256, HS384, HS512) use the same shared secret for both signing and verifying, while RSA and ECDSA algorithms (RS256/384/512, ES256/384/512) sign with a private key and verify with the matching public key — so verifying a token never requires knowing the private key.

This tool reads the algorithm out of the token's header automatically and asks for whichever key that algorithm needs. Everything — reading the token, importing the key, and running the cryptographic check — happens locally using your browser's built-in Web Crypto API. Nothing you paste here, including a secret, is ever sent anywhere.

• •A token with alg: "none" has no signature at all — this was a real, widely-exploited JWT vulnerability where attackers stripped the signature and set alg to none, and some careless libraries accepted it anyway. This tool always reports it as invalid, with no way to "verify" it.
• •For RSA and ECDSA algorithms, paste a public key, not a private key — a public key is safe to share and is all verification ever needs. If you only have a private key, export its public counterpart first.
• •A public key must be in SPKI PEM format, the block that starts with "-----BEGIN PUBLIC KEY-----". A "-----BEGIN RSA PUBLIC KEY-----" (PKCS#1) key is a different format and needs converting first (e.g. openssl rsa -pubin -in key.pem -pubout).
• •"Signature invalid" almost always means one of two things: the secret or public key doesn't match the one used to sign the token, or the token's header/payload was edited after signing. Either way, don't trust the token.