# JWKS explainer + key matcher > Paste a JSON Web Key Set to break down every key, flag any private material, and match a JWT to its key by kid. Nothing leaves your browser. - Tool: https://ronutz.com/en/tools/jwks-explainer - Family: Identity & tokens --- ## What it does Paste a JSON Web Key Set and the tool breaks it down key by key: for each key it reads the type, the key id, the intended use and algorithm, and the type-specific parameters, and it flags any key that contains private material. If you also paste a JWT, it matches the token to the key that should verify it by comparing key ids. Nothing leaves your browser. ## What a JWKS is A JSON Web Key Set (JWKS) is the JSON document an identity provider publishes, usually at `/.well-known/jwks.json`, so that anyone can verify the tokens it signs without a shared secret. It is simply a list of keys: { "keys": [ {JWK}, {JWK}, ... ] } Each entry is a JSON Web Key (JWK) describing one key: its type (`kty`, such as RSA, EC, or OKP), an optional key id (`kid`), what it is for (`use`, typically `sig` for signing or `enc` for encryption), the algorithm it goes with (`alg`), and the parameters specific to that key type. ## Public and private material This distinction is the security point of the tool. A JWKS published for verification should contain only public keys. Each key type has public parameters and private ones: an RSA key publishes its modulus and exponent (`n`, `e`) and keeps its private exponent (`d`) secret; an elliptic-curve key publishes its coordinates (`x`, `y`) and keeps its private scalar (`d`); a symmetric key (`oct`) is nothing but the secret (`k`). If a key in the set carries any of the private fields, it means private key material has been exposed, which is a serious mistake, so the tool flags it explicitly. ## Matching a token to its key A signed JWT usually names, in its header, the key id (`kid`) of the key that signed it. A verifier looks through the JWKS for the key with that `kid` and uses it. The tool does the same: given a JWT and a set, it finds the key whose `kid` matches the token's, which is exactly the lookup a real verifier performs before checking the signature. The key parameters follow RFC 7517 and RFC 7518, with the OKP key type for Edwards-curve keys (such as Ed25519) defined in RFC 8037. ## Using it Paste a JWKS to inspect every key and catch any exposed private material, and optionally paste a JWT to see which key in the set is the one meant to verify it. ## Standards and references - [RFC 7517: JSON Web Key (JWK)](https://datatracker.ietf.org/doc/html/rfc7517) - the JWK and JWK Set formats and their parameters - [RFC 7518: JSON Web Algorithms (JWA)](https://datatracker.ietf.org/doc/html/rfc7518) - the key-type parameters and the signature and encryption algorithms - [RFC 8037: CFRG Curves for JOSE (OKP, EdDSA)](https://datatracker.ietf.org/doc/html/rfc8037) - the OKP key type and EdDSA ## Related reading - [JWK Key Types: RSA, EC, OKP, and oct](https://ronutz.com/en/learn/jwk-key-types.md): Every JSON Web Key declares a kty, and that one field decides which parameters the key carries. Four types cover almost everything you will meet: RSA, elliptic curve, the Edwards and Montgomery curves, and the symmetric octet sequence. The crucial split in all of them is public versus private. - [JWK Parameters and Thumbprints](https://ronutz.com/en/learn/jwk-parameters-and-thumbprints.md): A JWK is a JSON object describing one key, and its parameters say what the key is for and how to identify it. Beyond the key material, kid names it and an RFC 7638 thumbprint gives it a stable, computed identifier. This covers the common parameters and how a thumbprint is derived and used. - [JWKS and Key Rotation: How Providers Publish Their Keys](https://ronutz.com/en/learn/jwks-and-key-rotation.md): A JWKS is the public phone book of signing keys that an identity provider publishes so anyone can verify its tokens. Understanding the keys array, the kid that names each key, and why a provider keeps more than one key at a time is the foundation of token verification. - [JWT Algorithm Confusion Attacks](https://ronutz.com/en/learn/jwt-algorithm-confusion.md): Two classic JWT verification failures come from trusting the token's own algorithm header: accepting alg none, and being tricked into verifying an RS256 token as HS256 using the public key as the secret. Both are defeated by pinning the expected algorithm on the server instead of reading it from the token. - [Verifying a JWT with a JWKS: From kid to Signature](https://ronutz.com/en/learn/verifying-a-jwt-with-jwks.md): Verifying a signed token is a short, strict sequence: read the header, find the key whose kid matches in the provider's JWKS, confirm the algorithm, and check the signature. Each step has a classic pitfall, and skipping the strictness is how verification bypasses happen.