JWT Verifier checks whether a JSON Web Token's signature matches a key you provide, and can sign a payload to make a test token. It supports HS256, HS384 and HS512 with a shared secret, RS and PS with RSA keys, and ES256, ES384 and ES512 with EC keys, using PEM, JWK or a certificate. Everything runs with the browser's Web Crypto; the key is never stored or put in a link.
How to read the result
Signature says VALID only when the token's signature was produced by the key you entered with the algorithm you expect. The expected algorithm is pinned: if the token header names a different one, the result is INVALID with the reason, and a token with alg: none is always rejected. Time claims (iat, nbf, exp) are converted to dates and compared with your clock. Header and payload are shown as formatted JSON.
Defender tips
- Pin the algorithm on the server. Letting the token header choose is how algorithm confusion attacks turn a public key into an HMAC secret.
- Use long random HMAC secrets. Short or dictionary secrets can be brute forced offline from a single token.
- Verify
aud,issandexpas well as the signature; a valid signature only proves who issued the token, not that it is meant for you. - Rotate keys with a
kidso old tokens can be retired without an outage.
FAQ
Is my secret or private key sent anywhere?
No. The key field is never written to the URL, the history or a share link, and signing and verifying happen in this tab.
Why is my RSA PEM refused?
Web Crypto accepts SPKI public keys (BEGIN PUBLIC KEY) and PKCS#8 private keys (BEGIN PRIVATE KEY). The error message gives the OpenSSL command to convert an older format.
Should I test production tokens here?
Prefer test tokens. Nothing leaves the browser, but a live token is still a credential on your screen.