JWT Signature Verifier is a free tool that checks whether a JSON Web Token really was signed by the key you expect. Paste the token and either the shared secret (for HS256) or the issuer’s public key — as PEM, a certificate, a JWK or a whole JWKS — and it tells you whether the signature is genuine. It supports HS256, RS256, PS256, ES256 and EdDSA, and it runs in your browser, so neither the token nor the key is uploaded.
How to verify a JWT
- Paste the token. The page reads its header and tells you which kind of key it needs.
- For HS256, HS384 or HS512, paste the shared secret. Tick “secret is base64-encoded” if your provider shows it that way.
- For any other algorithm, paste the issuer’s public key, its certificate, or its JWKS.
- Read the result: verified, invalid, or why it could not be checked.
Decoding is not verifying
Anyone can decode a JWT — the header and claims are only base64url — and anyone can make one with any claims they like. The signature is the only part that proves who issued it. TheJWT Decoder shows what a token says; this page checks whether it is telling the truth.
Finding the right key
Identity providers publish their public keys as a JWKS: a JSON list of keys, each with a kid. The address is in the provider’s OpenID configuration, at /.well-known/openid-configuration underjwks_uri. Open it, copy the JSON, and paste it here: the key the token names in its header is used. A PEM public key or the issuer’s certificate works just as well. Only the public key is needed; if you paste a private key it still works, but you are asked not to.
What this refuses, and why
Two mistakes have broken real login systems, and a verifier must refuse both. The first is alg: none: an unsigned token that some early libraries accepted as valid, so anyone could log in as anyone. The second is algorithm confusion: an attacker signs a token as HS256 using the server’s RSA public key as the secret, and a server that trusts the token’s own alg field accepts it. This page names both instead of checking them.
A valid signature is not the whole check
A genuine signature proves who issued a token and that it has not been altered. A server must still check that it has not expired, that iss and aud are the values it expects, and that the algorithm is the one it configured — never the one the token asks for. This page warns when a correctly signed token has expired. For signing webhook payloads rather than tokens, see the HMAC Generator.
Troubleshooting
- Invalid, with the right secret: check whether the secret is base64-encoded — many providers show it that way — and tick the box.
- Invalid, with a JWKS: the provider may have rotated its keys. Fetch the JWKS again.
- “No key in that set suits”: the token names a
kidthat is not in the JWKS you pasted, or the key types differ. - Five parts instead of three: this is an encrypted token (JWE), not a signed one. It needs a decryption key, not a verification key.
Frequently asked questions
Is it safe to paste a secret or key here?
The token, secret and key are checked in your browser and never sent to our servers or saved. A public key is public anyway. A shared secret is not: prefer a test secret where you can, and never paste a production secret into a site you do not trust.
Which key do I need?
It depends on the alg in the token’s header. HS256, HS384 and HS512 use a shared secret. RS, PS, ES and EdDSA tokens are checked with the issuer’s public key — usually published as a JWKS at the address in its OpenID configuration (jwks_uri). Paste that JSON and the right key is picked by the token’s kid.
The signature is valid. Can I trust the token?
It proves the token came from whoever holds the key and has not been altered. A server must also check that it has not expired, that the issuer (iss) and audience (aud) are the ones it expects, and that the algorithm is the one it expects — never whatever the token says.
Why does it refuse my HS256 token with a public key?
That is the algorithm confusion attack. An attacker takes a server’s RSA public key — which is public — and uses it as an HMAC secret to sign a forged HS256 token. A server that trusts the token’s alg field would accept it. A correct verifier fixes the algorithm in advance, so this page refuses the combination.
Why does it reject alg "none"?
A token with alg "none" has no signature at all, so anyone can write any claims into it. Some early JWT libraries accepted these as valid, which let attackers log in as anyone. Every verifier must reject them.
Last updated