JWKS Generator — Build a /.well-known/jwks.json Endpoint

A JWKS (JSON Web Key Set, RFC 7517) is a JSON document with a top-level 'keys' array of JWKs. It's the standard way to publish public keys so that clients can verify JWTs your service signed. Typical setup: your backend signs JWTs with a private key you keep secret, and hosts the matching public key(s) at /.well-known/jwks.json. Client libraries fetch that URL, cache it, and use the kid claim in each JWT to pick the right key.

kid stands for 'Key ID' — a string identifier that lets JWT verifiers know which key to use when you rotate. This tool defaults to computing a SHA-256 JWK Thumbprint per RFC 7638, which is a deterministic hash of the public key's essential fields. Same key → same kid → clean rotation semantics. You can override with a custom string (e.g. '2026-q3', 'auth-signer-1') if you prefer.

Yes — the tool auto-strips private components (d, p, q, dp, dq, qi, oth) before serialising. But be careful: your private key still passes through this tool's memory. Everything is client-side and nothing is uploaded, but for production keys, prefer to paste only the public halves. Use our Public Key Extractor first if you want to be extra defensive.

If you leave alg blank, the tool guesses based on key type: RSA → RS256, EC P-256 → ES256, P-384 → ES384, P-521 → ES512. Override to PS256 / PS384 / PS512 if you use RSA-PSS instead of RSASSA-PKCS1-v1_5. The alg claim is a hint to verifiers — many JWT libraries also honour it as a security check against algorithm substitution attacks.

Save the JSON as jwks.json and serve it from your web server or CDN at https://your-domain/.well-known/jwks.json with Content-Type: application/json. Set a moderate Cache-Control (5–15 minutes is typical) so verifiers can cache it but still notice rotation reasonably quickly. Most JWT libraries (jsonwebtoken, jose, node-jose, PyJWT, jose4j) have a jwksUri option that handles fetching and caching automatically.