Developer
Encoders, converters & dev utilities
Verify a JWT Signature — HS256 / RS256 / ES256 In-Browser
Verifying a JWT proves it was issued by a party holding the signing key and has not been tampered with — this is what decoding alone cannot do. Verification recomputes the signature over the exact string header.payload and compares it to the token's third part, using the Web Crypto SubtleCrypto API in your browser. For HS256 (symmetric) you supply the shared secret and the tool checks HMAC-SHA256; for RS256 you supply the RSA public key (or JWKS) and it checks an RSA PKCS#1 v1.5 signature; for ES256 you supply the EC P-256 public key and it checks an ECDSA signature. Crucially, the tool pins the verification algorithm to the key type rather than blindly trusting the token's alg header — that is what stops the alg:none and HS/RS key-confusion attacks. All verification runs client-side; keys and tokens never leave your browser. Free, no login.
Verify = recompute the signature over header.payload with the correct key, then compare to part 3
- HS256 (symmetric): HMAC-SHA256 with the shared secret — same key signs and verifies
- RS256 (asymmetric): RSA PKCS#1 v1.5 verify with the RSA public key or JWKS
- ES256 (asymmetric): ECDSA over the NIST P-256 curve with the EC public key
- Runs via Web Crypto (SubtleCrypto) in-browser — no server, no key upload
- Security: alg:none is never accepted as verified; the expected algorithm is pinned to the key type
- Worked example — an HS256 token verifies "Valid" only when HMAC-SHA256(secret, header.payload) equals the signature
Frequently asked questions
How do I verify a JWT signature?
Verification recomputes the signature over the string header.payload and compares it to the token's signature part. Which operation runs depends on the algorithm in the header: HS256 uses HMAC-SHA256 with a shared secret you provide; RS256 uses RSA PKCS#1 v1.5 with the issuer's RSA public key (or a JWKS URL); ES256 uses ECDSA on the P-256 curve with the EC public key. Paste the token and the key/secret and the tool verifies it in your browser using the Web Crypto API, returning Valid or Invalid without sending anything to a server.
What key do I need — a secret or a public key?
It depends on the algorithm. HS256 is symmetric, so verification needs the same shared secret that signed the token. RS256 and ES256 are asymmetric: they are signed with a private key and verified with the matching public key (often published as a JWKS). You should never need a private key to verify an asymmetric token — the public key is enough. If a tool ever asks you to paste an RSA private key to verify RS256, that is wrong. This verifier accepts the shared secret for HS256 and the public key/JWKS for RS256/ES256.
Why does the algorithm matter for security?
Because two classic attacks exploit a verifier that trusts the token's own alg header. First, alg:none claims the token is unsigned — a correct verifier must never treat that as valid. Second, the HS/RS key-confusion attack: an attacker takes an RS256 setup (verified with a public key) and flips the header to HS256, then signs with the public key as the HMAC secret — since the public key is public, anyone can forge a "valid" token. The defence is to pin the expected algorithm to the key type instead of letting the header choose. This verifier does exactly that.