Why it matters
A JWT decoder shows what a token claims, but anyone can write a token that claims anything. What makes a token trustworthy is its signature, checked against the issuer's key, and then its claims: has it expired, is it for your API, did the right issuer make it. Doing that by hand means writing code, and pasting production tokens into an unknown website to check them is a risk in itself.
This verifier does the whole check in your browser with WebCrypto, the same cryptography the browser uses for HTTPS, and sends nothing anywhere. Paste the issuer's JWKS (from its jwks_uri), a PEM key or certificate, or a shared secret. It picks the key by kid, verifies the signature, and checks exp, nbf, iat, iss and aud with the clock skew you allow. It also flags the classic mistakes: alg none, an HS256 token checked against a public key (algorithm confusion), ECDSA signatures in the wrong encoding, and tokens that live for days.
How to use it
- Paste the token.
- Paste the issuer's JWKS, a public key, a certificate or the shared secret.
- Add the issuer and audience you expect.
- Read the verdict, the claim checks and the warnings.
FAQ
Is it safe to paste a real token?
The token never leaves your browser: verification uses WebCrypto on your device. Even so, treat live tokens as secrets and prefer expired or test ones.
Where do I get the JWKS?
From the issuer's discovery document, at /.well-known/openid-configuration, under jwks_uri. Paste the JSON it returns.
What is algorithm confusion?
A bug where a server reads the algorithm from the token. An attacker sets alg to HS256 and signs with your public key as the secret. Verifiers must decide the algorithm from the key, never from the token.
Can it decrypt JWE tokens?
No. Encrypted tokens (five parts) need the recipient's private key. The page recognises them and says so.
