JWK and JWKS Viewer

Read a JWK or JWKS set properly - key type, use, algorithm, key ID, operations - with thumbprints calculated and duplicate or inconsistent keys flagged.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

JWK or JWKS A single key object or a full key set. Read in your browser.

The two things that actually go wrong with key sets

A JWKS is usually fine until it is not, and when it is not it is almost always one of two things - neither of which is visible reading the keys one at a time.

Duplicate kid. Two keys sharing an identifier means a verifier looking one up gets whichever it happens to find first. Signature checks then pass or fail depending on key order in a JSON document, which is about the hardest class of bug to reproduce - it works on staging, fails in production, and works again after a restart.

Private key material in a published document. A JWKS is served at a public URL by design. A key object that still carries d, p or q is a private key on the internet, and every token it ever signed has to be treated as forgeable. It happens when somebody exports a key pair rather than its public half, and nothing in the export complains.

Thumbprints, computed properly

RFC 7638 defines a key's thumbprint as the SHA-256 of a canonical JSON object containing only the required members for that key type, ordered lexicographically, with no whitespace. Include an extra member or get the order wrong and you produce a hash that is stable, plausible, and matches nobody else's.

The implementation here is checked against the worked example published in the RFC itself, so a thumbprint from this page is the same one your identity provider computes. It is what lets you confirm two differently-formatted copies of a key are the same key.

What else it reports

Key type, curve and size, with RSA below 2048 bits flagged
Missing kid, which makes rotation a flag day rather than an overlap
use values outside the two the RFC defines
An alg that disagrees with the key type it is attached to
oct keys, which are symmetric secrets with no public half and should never appear in a published set
The same key published twice under different identifiers - harmless, but usually a rotation that never finished

Nothing is uploaded

Parsing and thumbprinting both happen in your browser with Web Crypto. That matters more here than on most pages: people paste private keys into key viewers by accident constantly, and a tool that posts its input to a server turns that slip into an incident.

Frequently asked questions

Where do I get my JWKS?

Most identity providers publish it at a jwks_uri listed in their OpenID Connect discovery document, typically /.well-known/openid-configuration. The OIDC Discovery Analyzer will point you at it.

My thumbprint doesn't match the one my provider shows.

Check whether they are using SHA-256 - the RFC's default - and whether they are showing base64url or hex. Both forms are displayed here. If they still differ, the keys are genuinely different.

It says my key is private. It came straight from my provider.

Then you have almost certainly been given the signing key rather than the verification key, which is a serious problem worth raising with them immediately. Check for a d member - that is the private exponent.

Is a duplicate kid always a bug?

In practice, yes. The specification does not forbid it, but no verifier defines which key wins, so the behaviour is whatever your library happens to do. Give each key a distinct identifier.

Are my keys uploaded?

No. Everything runs in your browser.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.