JWKS Key Set Viewer
Decode a JWKS key set — kid, kty, alg, use, key_ops, x5c chains — and convert JWK ↔ PEM.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
A JWK Set is the JSON document behind a jwks_uri: a keys array where each entry describes one public key in JSON form. This viewer decodes each key — kid, key type, algorithm, use and key_ops, the RSA modulus size or EC curve, and the x5c certificate chain rendered back as PEM certificates — and converts RSA/EC keys between JWK and PEM both ways. Structure errors (a missing kty, base64url that does not decode, duplicate kids) are reported with what to fix rather than a blank output. Everything happens locally in your browser.
When to use it
Questions
What is a JWKS and where does it come from?
It is the public-key half of a JWT-based system, published as JSON so verifiers can fetch signing keys without a manual exchange: {"keys": [ ... ]}, one JWK per key. Identity providers expose it at a well-known URL (often /.well-known/jwks.json or a jwks_uri in the OIDC discovery document). Paste that document here and every key is broken out for reading.
What is the x5c member and how is it decoded?
x5c is an optional JWK member carrying the key's X.509 certificate chain, leaf certificate first, each entry standard base64 (not base64url) of a DER certificate. The viewer decodes every entry back to a readable PEM certificate and shows the leaf's subject and issuer — these are certificate claims, not proof of a trusted identity. The key material the JWK carries and the leaf certificate's key are two views of the same key when x5c is honest.
How do I convert a JWK to PEM (or back)?
Use the JWK → PEM tab for RSA and EC public keys: the output is a SubjectPublicKeyInfo PEM, the form openssl pkey -pubin and every TLS stack accept. The PEM → JWK tab does the reverse and also accepts PKCS#1 (BEGIN RSA PUBLIC KEY) PEMs. Certificates and private keys are deliberately refused — a certificate is not a key, and pasting a private key here is never useful.
Why did I get a warning about duplicate kids?
kid is a name a key-set author assigns; it is not a fingerprint and nothing enforces uniqueness. RFC 7517 says kids in a set SHOULD be distinct because token headers reference keys by kid — a duplicated kid makes verification ambiguous. The viewer flags the collision and keeps decoding; RFC 7517 allows exceptions such as equivalent keys with different key types, but reusing an identifier for unrelated rotated keys can make key selection ambiguous.
Does decoding mean the key is valid or trustworthy?
No. Structure and cryptography are different checks: this tool proves the JSON is a well-formed JWK — the base64url members decode, the sizes match the declared curve — and nothing more. A well-formed JWK can still encode a bogus point or a key nobody attests to. Whether a key is trustworthy comes from how you obtained the JWKS (TLS, the discovery document), not from decoding it.
How do I investigate a JWT whose kid is missing from the JWKS?
Read kid and alg with the JWT Decoder, then inspect a JWKS obtained through your application's configured trusted issuer. Compare the key IDs, key types and allowed algorithms. A missing key may mean stale cached keys, a different issuer or key rotation; consult the issuer's documentation before changing verifier settings. Do not trust a key source just because the token names it. Matching kid identifies a candidate key, not a verified signature.