Skip to content

JWKS Verifier

Fetches a JWKS endpoint, picks the key by kid and verifies a token’s signature and standard claims.

Verifies a token against an issuer’s published JWKS — fetch it by URL or paste it — picking the key by `kid`, checking the signature, and then checking `exp`, `nbf` and, if you name them, `iss` and `aud`. The token is never sent; only the JWKS URL is fetched.

🔒 Runs entirely in your browserjwtjwksauthverify

The token does not leave this tab.

Signature checking is done by the browser’s WebCrypto and this page has no server side. The only network request is one GET to the JWKS URL you type, and that request carries nothing but the URL — not the token.

Token

A Bearer prefix is stripped for you.

Public keys (JWKS)

Key source

The browser GETs it directly. The token is not sent.

The `jwks_uri` in the issuer’s /.well-known/openid-configuration is this address.

Expected values (optional)

Clock skew allowance

Leave one empty and that claim is not checked. exp and nbf are always checked.

What is checked

  • · RS256/384/512, PS256/384/512, ES256/384/512 and EdDSA (Ed25519) are verified with WebCrypto (RFC 7518 §3, RFC 8037). HS* uses a shared secret and cannot be checked against a JWKS at all — the JWT decoder checks those with the secret. ES256K and Ed448 are not in any browser’s WebCrypto.
  • · The key is chosen by the kid in the token header (RFC 7515 §4.1.4). During a key rotation a JWKS holds several keys, so a kid that does not match is reported as such.
  • · exp and nbf are checked with the skew allowance; iss and aud only when you give an expected value (RFC 7519 §4.1). alg: none is always refused.

How to use it

  1. Paste the token

    Its `alg`, `kid` and issuer are read out immediately, which is what tells you which JWKS you need.

  2. Fetch or paste the key set

    The issuer’s `/.well-known/openid-configuration` names its `jwks_uri`. Google, Microsoft and Apple have shortcut buttons; anything else you type or paste.

  3. Fill in what you expect

    An `iss` and `aud` you leave empty are not checked at all — which is how a token meant for another audience gets accepted in real systems. The clock-skew allowance covers servers that disagree by a minute.

  4. Read the verdict and the claim table

    The banner says accept or do not accept; the table under it says which check produced that answer and which key was selected.

Common questions

The fetch failed with a CORS error.

A JWKS endpoint has to send CORS headers for a browser to read it. Google, Microsoft and Apple do; plenty of self-hosted issuers do not. Fetch it yourself with curl and paste the JSON — the verification is identical either way.

It says no key matches the kid.

Usually a key rotation: the token was signed before the issuer rotated, and the JWKS now holds only the newer keys. It can also mean the token came from a different issuer than the JWKS you fetched.

Why is `alg: none` always refused?

Because accepting it is the classic JWT vulnerability: an attacker rewrites the header, drops the signature, and a library that trusts the header lets the token through. There is no legitimate use for it in a verification path.

Can it check an HS256 token?

Not here — HS* is a shared secret and a JWKS publishes public keys. Use the JWT decoder, which takes a secret. An issuer publishing HMAC keys in a JWKS would be publishing the ability to mint tokens.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.