JWKS Builder
Assemble several public keys into one JSON Web Key Set, with an RFC 7638 kid per key, a private-key leak guard, and duplicate-kid checking, ready to host at /.well-known/jwks.json.
Keys in this set
0 keysAbout JWKS Builder
A JWKS is the { "keys": [ ... ] } document an OIDC or OAuth2 issuer (or an internal JWT scheme) publishes at its jwks_uri so verifiers can fetch the public keys that validate tokens. Most key generators online make one key at a time. This builder does the next step: it collects several public keys into one set. That is exactly what you need during a key rotation, where the old key and the new key have to be published together for an overlap window so tokens signed by either still verify. Add each key as PEM (PKCS#8 or SPKI) or JWK JSON, set its use (sig or enc) and alg, and the builder fills a deterministic kid from the RFC 7638 thumbprint. You can also set the kid yourself. If you paste a private key, it warns you and strips the private members before the key enters the set, because a JWKS holds public material only. A verifier picks a key by its kid, so each kid in the set has to be unique; a duplicate-kid check flags two keys that share one before it breaks key selection. You can mix RSA and EC keys in the same set, copy the document pretty or minified, and download it ready to host. Everything runs in your browser with the Web Crypto API, so a key you paste is never uploaded. To convert a single key between formats, reach for the PEM and JWK Converter; to mint a signing key first, use the JWT Generator.
How to build a JWKS
- Click Add key and choose PEM or JWK for each one.
- Paste each public key (PEM PKCS#8/SPKI or JWK JSON). If a key is private, click Strip to public; a JWKS holds public keys only.
- Set use (sig or enc) and alg per key if your verifier needs them.
- Leave Auto kid on for an RFC 7638 thumbprint kid, or set your own; keep every kid unique.
- Add a second key beside the first when you are rotating; both stay in the set during the overlap window.
- Copy the set pretty or minified (or download it) and host it at /.well-known/jwks.json over HTTPS with Content-Type: application/json.
Common Use Cases
Stand up a jwks_uri
Publish a JWKS for an OIDC or OAuth2 issuer from your existing public signing key, so clients can fetch it and verify the tokens you issue.
Rotate signing keys with no downtime
Put the new key alongside the old one in the set. Verifiers see both during the overlap window, so tokens signed by either key keep validating while you switch the signer over.
Mix RSA and EC keys
Build a set that holds both key types when different services sign with different algorithms (for example one service on RS256 and another on ES256).
Combine keys from several sources
Assemble one document from public keys exported by different teams or vaults, each with its own kid, so verifiers can resolve any of them.
Frequently Asked Questions
What is a JWKS and how is it different from a single JWK?
A JWK is one key, written as a JSON object. A JWKS (JSON Web Key Set) is a wrapper, { "keys": [ ... ] }, that holds one or more JWKs. The set is what you host at a jwks_uri, because it lets verifiers pick the right key by kid and lets you publish more than one key at a time.
Why does a JWKS contain multiple keys?
Mostly for rotation. When you replace a signing key, the old key and the new key both need to be in the set for a while: tokens already issued under the old key are still in flight, and tokens signed by the new key need to verify too. Publishing both during an overlap window means no token fails to verify during the switch.
How do I build a jwks.json from one or more public keys?
Add a key for each one, paste it as PEM (PKCS#8 or SPKI) or as JWK JSON, and set use and alg if your verifier needs them. The builder normalises each key to a public JWK, fills a kid, and assembles them into one { "keys": [ ... ] } document you can copy or download.
How do I add a new key to my JWKS during a rotation without downtime?
Add the new key beside the old one so both are published in the set. Keep verifiers reading that set, then switch your signer to the new key. Once the maximum token lifetime has passed (no token signed by the old key can still be valid), remove the old key from the set.
Should a JWKS ever contain a private key?
No. A JWKS is meant to be fetched by anyone who needs to verify your tokens, so it must carry public material only. If you paste a key that still has its private members (d, p, q, dp, dq, qi), this tool flags it and drops those members before the key enters the set, so the output is always public-only.
What is the kid and how is it derived?
The kid (key ID) is the identifier a verifier uses to pick the right key out of the set. With Auto kid on, this tool derives it from the RFC 7638 JWK thumbprint, a SHA-256 hash of the key's canonical public members. The id is content-derived, so it stays stable for a given key and two distinct keys land on different values. You can also set a kid by hand if your system expects a specific value.
Where do I host jwks.json?
Serve it at /.well-known/jwks.json over HTTPS with Content-Type: application/json. Add a Cache-Control max-age so verifiers can cache it instead of refetching on every token check. The jwks_uri in your OIDC discovery document should point at that URL.