# JWT Verifier

Check whether a JSON Web Token is genuine and still current. Paste the token together with its HMAC secret, a PEM public key, a certificate, a JWK or a whole JWKS, and the verifier checks the signature with the jose library, compares exp and nbf with the current time and an optional clock tolerance, and gives a clear verdict next to the decoded header and claims. Tokens with alg none are refused.

## Frequently asked questions

### What does the verifier check?

It checks the signature against the key you provide, then compares the exp claim and the nbf claim with the current time. The verdict is valid only when the signature matches and neither time check fails. Claims such as iss, aud or sub are shown in the payload but not compared against expected values.

### Which keys can I paste?

For HS256, HS384 and HS512 paste the shared secret as text or as an oct JWK. For RSA, EC and EdDSA tokens paste a PEM public key (SPKI or PKCS #1), an X.509 certificate, a public or private JWK, a JWKS with up to 50 keys, or a private PEM key, from which only the public part is used.

### How is the right key chosen from a JWKS?

If the token header has a kid, the key with the same kid in the set is used, and an error names the kid when none matches. Without a kid the set must contain exactly one key. This mirrors how most servers select keys from a jwks_uri document.

### What does the algorithm option do?

With Use the token's alg, the algorithm comes from the token header, but the key still has to fit it, so an RSA public key can never be used as an HMAC secret. Pick a specific algorithm to also require that the token uses it, which is how a server should pin its expected algorithm. A token with another alg is then rejected with both names shown.

### Why is a token with alg none refused?

A token with alg none carries no signature, so there is nothing to verify and anyone could have written it. Accepting such tokens is a well known vulnerability in JWT libraries. The verifier reports it as an error instead of a valid result.

### How do exp, nbf and the clock tolerance work?

A token counts as expired when exp is at or before the current time, and as not yet valid when nbf is later than the current time. The clock tolerance, from 0 to 3600 seconds, extends both checks to allow for clock drift between servers. Claims that are present but not numeric make the token invalid.

### What does an invalid signature mean?

The token was not signed with the key you provided, or its header or payload was changed after signing. Check that you pasted the matching public key or secret, including its exact characters, and that the token was copied completely. The decoded header and payload are still shown so you can compare them.

### Which algorithms are supported?

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 and EdDSA with Ed25519 keys. RSA keys must have at least 2048 bits. Encrypted tokens (JWE) are not decrypted.

### Is the token or key stored?

No. The token and key are used only for this verification in memory and are never logged or saved. A public key is safe to share, but treat HMAC secrets with care and rotate any secret you suspect has leaked.

### How large can the token and key be?

Tokens may be up to 65,536 characters, and the key field up to 262,144 characters, which fits large JWKS documents. The token must have three base64url parts separated by dots, a JSON header with an alg member and a JSON object as its payload.

Your ad here?

[Email us](mailto:hi@dennn.is?subject=Advertising%20on%20OneClick%20Pro)

[Ad The agent-ready plugin suite for WordPress.](https://sleekwp.com/?ref=oneclickpro)