Skip to main content
Bethemesh
Security & privacy

JWK / JWKS Inspector

Paste a JWK or JWKS to get a table per key (kid, kty, alg, use, key_ops, RFC 7638 SHA-256 thumbprint) and warnings: missing kty or kid, duplicate kid, private key material published by mistake.

  • Clipboard

Embed this widget

Customize the result, check the live preview, then copy the code.

Preview

Embed code type

Code to copy

Responsive and automatically resized by Bethemesh.

Was this tool useful?

How does this tool work?

The JWK / JWKS inspector makes a JSON Web Key set readable, such as the one published at an OpenID Connect provider’s jwks_uri. It is for developers and security teams who publish or consume a JWKS and want to see at a glance which keys it contains, how they are identified and whether any private data was included by mistake.

A JWK (RFC 7517) describes a key in JSON: kty gives the family (RSA, EC, oct), kid the identifier, alg the intended algorithm, use the purpose (sig for signatures, enc for encryption) and key_ops the allowed operations. A JWKS is simply a {"keys":[…]} object that groups several of them. The tool accepts both forms, shows one row per key and summarizes the number of keys, the key types and the distinct kid values. It also computes each key’s RFC 7638 thumbprint: the Base64URL-encoded SHA-256 hash of a canonical JSON containing only the required members in alphabetical order, that is e, kty and n for RSA, crv, kty, x and y for EC, and k and kty for a symmetric key.

The warnings target real publishing mistakes: a missing kty (the key is unusable), a missing kid when the set holds several keys (the verifier cannot tell which one to use), a duplicate kid, and above all private material. For RSA, the d, p, q, dp, dq and qi members are the private key; for EC it is d; for a symmetric oct key, the k member is the secret itself. A public JWKS must only contain public keys, otherwise anyone can sign tokens on your behalf. The result can be exported as JSON.

How to use this tool

  1. Paste the JWK or JWKS

    Paste a single key {"kty":…} or a full set {"keys":[…]}, for example copied from your provider’s jwks_uri.

  2. Read the key table

    For each key, review kid, kty, alg, use, key_ops and the RFC 7638 SHA-256 thumbprint, plus the summary of key count, types and distinct kid values.

  3. Handle the warnings

    Fix missing kty or kid values and duplicate kid values, remove any private data, then export the result as JSON if needed.

Use cases

Check a JWKS before publishing it

Before putting /.well-known/jwks.json online, make sure no key contains d or k and that every key has a unique kid.

Follow a key rotation

Paste your provider’s JWKS (Auth0, Keycloak, Entra ID, Google) during a rotation to see the old and new keys side by side, with their kid and thumbprint.

Find the key that signed a token

Compare the kid from a JWT header with those in the JWKS to identify the expected key, then check the signature with the JWT verifier.

Tips and best practices

  • A private key warning on an already published JWKS means the key must be revoked and replaced: removing it from the file is not enough, it may already have been copied.
  • Avoid a kid derived from a counter or a predictable date when you can use the RFC 7638 thumbprint: it is stable and identical regardless of JSON formatting.
  • A symmetric oct key never belongs in a public JWKS: HMAC secrets are shared out of band, through a secrets manager.

Frequently asked questions

What is the difference between a JWK and a JWKS?

A JWK is a single key represented in JSON, with fields such as kty, n, e or x and y. A JWKS (JSON Web Key Set) is a {"keys":[…]} object holding a list of JWKs, usually published by an authorization server so that clients can verify its tokens.

What is a JWK thumbprint?

It is an identifier computed as defined in RFC 7638: the SHA-256 of a canonical JSON containing only the required public key members, Base64URL-encoded. Two representations of the same key always give the same thumbprint, and a private key’s thumbprint is that of its public key. Many providers use it as the kid.

Is kid required in a JWKS?

RFC 7517 makes it optional, but as soon as a JWKS holds several keys it becomes essential: the kid in the JWT header is what selects the right key. Without it, the verifier has to try every key, which many libraries refuse to do.

How can I tell whether a JWK contains a private key?

An RSA JWK is private if it contains d (and often p, q, dp, dq, qi); an EC JWK is private if it contains d; an oct key always holds the secret in k. The tool flags these members. An RSA public key only contains kty, n and e, plus optional metadata.

What do kty RSA, EC and oct mean?

RSA is an RSA key used for example with RS256 or PS256; EC is an elliptic curve key (P-256, P-384, P-521) used with ES256, ES384 or ES512; oct is a symmetric key, a secret sequence of bytes used with HS256 or for AES encryption.

What is the difference between use and key_ops?

use states the key’s general purpose: sig for signatures, enc for encryption. key_ops lists the exact allowed operations, such as verify, sign, encrypt or wrapKey. RFC 7517 recommends not using both together or, if you do, keeping them consistent.

Related tools

Keep going with these tools

Tools similar or complementary to this one.

Works well with

JWT Signature Verifier

Verify a JWT signature with an HMAC secret or a JWK, JWKS or PEM public key, then check exp, nbf, iss and aud.

Security & privacyUse this tool

JWT Decoder

Decode a JWT to read its header, payload, claims and expiration dates.

Security & privacyFeaturedUse this tool

OAuth PKCE Generator

Generate a PKCE code_verifier, its S256 code_challenge and a state for your OAuth authorization request.

Security & privacyNewUse this tool

Read next

TutorialBest practicesBeginner

How to securely redact a PDF before sharing it

Learn why covering text is not enough, how secure PDF redaction removes sensitive information and why sanitization matters before sharing.

10 September 20262 min