JWT + JWKS Verifier (Public Key Discovery)

Production JWT verifiers typically fetch the public key from a JWKS endpoint — the issuer's standard endpoint that lists current signing keys. This tool does that handshake in the browser: paste the JWT and the JWKS URL (or issuer URL — we'll find the JWKS), and get verification + decoded claims.

How to use the JWT + JWKS Verifier (Public Key Discovery)

Paste a JWT and its issuer's JWKS endpoint URL. Click verify. The tool fetches the JWKS, finds the matching key (by kid header), and validates the signature.

CORS note: the JWKS endpoint must allow cross-origin GET from codeswap.net. Most providers do (Auth0, Okta, AWS Cognito) but some lock it down.

How JWKS makes verification self-service

A token signed with RS256 or ES256 is verified with a public key — but which one? Issuers publish their current public keys at a JWKS endpoint, a JSON document listing one or more keys, each tagged with a key ID. The token's header carries a matching kid, so a verifier fetches the JWKS, picks the key whose ID matches, and checks the signature with it. This lets issuers rotate keys without redeploying every service that trusts them.

This tool performs that whole handshake in the browser: paste a JWT and the issuer's JWKS URL, and it fetches the key set, selects by kid, verifies the signature, and decodes the claims. Because the fetch happens from your browser, the JWKS endpoint must permit cross-origin requests — the big identity providers (Auth0, Okta, AWS Cognito) generally do, though some self-hosted setups lock it down.

Common use cases

  • End-to-end verification — confirm a real token from your identity provider verifies against its live public keys.
  • Key rotation debugging — check whether a token's kid still matches a key in the current JWKS.
  • Issuer onboarding — verify a new provider's JWKS endpoint returns usable keys before wiring it into your app.
  • Incident triage — when logins start failing, see if the JWKS is reachable and the signature still checks out.
  • Learning OIDC — watch how discovery turns an issuer URL into a verified, decoded token.

Frequently asked questions

What is a kid and why does it matter?
The kid is a key ID in the JWT header that names which key signed the token. When an issuer publishes several keys in its JWKS — common during rotation — the verifier uses the kid to pick the right one rather than trying each.

Why might the fetch fail with a CORS error?
Your browser is requesting the JWKS from a different origin, and the endpoint must send headers allowing that. Managed providers usually do; a JWKS served by your own backend may need its CORS policy opened, or you verify server-side instead.

How is this different from the plain JWT decoder?
The decoder needs you to supply the key or secret. This tool discovers the public key automatically from the JWKS endpoint, which mirrors how production RS256/ES256 verification actually works.

Does verifying the signature mean the token is valid?
A good signature proves the token is authentic and untampered, but you still must check the claims — that it has not expired, the issuer and audience match, and any scopes you require are present.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: