JWT Verifier — Validate JWT Signatures Online (HS / RS / PS / ES)

Three things: (1) the signature is mathematically valid for the given key and algorithm, (2) the alg header matches a supported algorithm — including flagging the classic 'alg: none' vulnerability, (3) the standard time claims exp (expired?), nbf (not yet valid?), and iat (issued in the future?). Time checks are informational — an expired token still shows as signature-valid if the crypto is correct.

It depends on the algorithm in the JWT header. For HS256/384/512, paste the raw shared secret string used to sign it. For RS256/384/512 or PS256/384/512, paste the RSA public key in SPKI PEM (-----BEGIN PUBLIC KEY-----) or JWK format. For ES256/384/512, paste the EC public key (also SPKI PEM or JWK, with the right curve for the algorithm: ES256→P-256, ES384→P-384, ES512→P-521).

Common causes: (1) The key you pasted is the private key instead of the public key — this tool needs the public key for RS/PS/ES. (2) Curve mismatch — ES256 requires P-256 exactly, using a P-384 key gives an invalid signature. (3) The token was tampered with after signing. (4) Copy-paste added whitespace or missing BEGIN/END markers. Look at the specific error message; the Web Crypto API's messages are usually precise.

No. Verification runs entirely in your browser via crypto.subtle.verify. You can confirm with DevTools Network panel — no request fires when you paste a token. That said, don't paste production secrets or private keys into any online tool you can't fully inspect — the source is available on GitHub if you want to audit.

Historically, some JWT libraries accepted tokens with alg="none" (unsigned) as valid — an attacker could strip the signature and the server would trust the payload. RFC 7518 requires that unsigned tokens MUST NOT be accepted when signature verification is enabled. This tool always flags alg="none" as invalid regardless of the payload.