JWK Generator
Generate JSON Web Keys (JWK) for token signing and validation.
JWK Generator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The JWK Generator produces a JSON Web Key — the JSON representation of a cryptographic key used across the modern web token ecosystem, including JWT signature verification, OAuth 2.0 authorization servers' published key sets, and any API that needs to exchange key material in a JSON-native format rather than PEM's text-wrapped binary encoding.
- A JWK's exact fields depend on the key type and intended algorithm: an RSA signing key needs kty (key type), n and e (the modulus and public exponent), alg (the specific algorithm, like RS256), and typically a kid (key ID) so a verifier can pick the right key out of a set; an EC key instead carries crv, x, and y describing a point on a named curve. This tool generates a complete, correctly-shaped JWK for the algorithm you choose, sparing you from hand-assembling a JSON structure whose field requirements vary by key type.
- This is a testing and prototyping tool, distinct from the Authentication hub's JWT Generator: that tool builds a signed token; this one builds the key material a token's signature might be verified against, in the specific JSON format modern JOSE (JSON Object Signing and Encryption) libraries expect.
How It Works
- You choose an algorithm (such as RS256 or ES256), which determines both the underlying key type (RSA or EC) and the field shape the resulting JWK needs.
- A key ID (kid) is generated to let a verifier reference this specific key when multiple keys are published together in a JSON Web Key Set (JWKS).
- The key-type-specific fields are populated — n and e for RSA keys, or crv, x, and y for elliptic curve keys — along with kty, use, and alg.
- The resulting JWK is output as formatted JSON, ready to use directly or include in a JWKS document alongside other keys.
Usage
- Choose the algorithm you want the JWK to support (e.g. RS256 for RSA, ES256 for elliptic curve).
- Generate the key.
- Copy the resulting JWK JSON.
- Use it directly for local testing, or include it alongside other keys in a JWKS document for a service's published key-set endpoint.
Examples
- Generating an RS256 JWK to test a service's JWT verification logic against a known key before wiring up real certificate-backed key issuance.
- Producing an ES256 JWK to compare its field shape (crv, x, y) against an RS256 key's shape (n, e) when deciding which algorithm family a new service should use.
- Creating several test JWKs with distinct kid values to simulate a JWKS endpoint that publishes multiple keys during a key-rotation testing scenario.
- Generating a JWK to convert into PEM format afterward using the JWK ↔ PEM Converter, for a library that needs the key in the other format.
Real-World Use Cases
- Generating a test JWK to configure a service's JWKS endpoint during development, before wiring up real key management infrastructure.
- Prototyping the exact field shape a JOSE library expects for a given algorithm, before writing production key-generation or key-rotation code.
- Producing a throwaway key in JWK format for local testing of JWT signature verification logic, without needing to convert from a PEM-formatted key by hand.
- Understanding the difference between RSA and EC JWK field shapes (n/e versus crv/x/y) before choosing which algorithm family to standardize on.
Best Practices
- Always assign a distinct kid to each key in a published JWKS — it's what lets a verifier select the correct key when more than one is present, especially during key rotation.
- Match the alg field to how the key will actually be used — a verifier should reject a token whose declared algorithm doesn't match the key's own configured algorithm, as a defense against algorithm-confusion attacks.
- Treat any key generated in a browser tool as a test artifact only — real signing keys backing production JWKS endpoints should come from a proper key management system, not a browser-generated value.
- Prefer EC keys (ES256 or similar) over RSA for new systems where smaller token and key sizes matter, since elliptic curve keys achieve comparable security at a fraction of RSA's size.
Common Mistakes
- Publishing a JWKS without a kid on each key, making it impossible for a verifier to disambiguate which key to use once more than one is present, particularly during rotation.
- Confusing a JWK's use field (sig for signing, enc for encryption) with the alg field (the specific algorithm) — both matter, and a mismatch between what a key is intended for and how it's actually used is a real interoperability bug.
- Assuming an RSA and an EC JWK are interchangeable in a library's configuration — the field shapes are entirely different (n/e versus crv/x/y), and code expecting one will not correctly parse the other.
- Generating a production signing key with a browser-based tool rather than a proper key management system — fine for testing, but a genuine risk for anything backing real authentication.
Limitations
- This tool generates a JWK for testing and prototyping in your browser; it is not a substitute for a production key management system responsible for real signing keys.
- Only the common signing algorithms (RS256/RS512/ES256/ES384 and similar) are covered — verify against your specific library's supported algorithm list before assuming full coverage.
- Generated key material exists only in local browser memory during the session and is not persisted.
Technical Reference Guide
- The JSON Web Key format, including the field requirements for different key types, is defined by RFC 7517.
- The specific algorithms a JWK's alg field can declare (RS256, ES256, and similar), along with each algorithm's required key parameters, are defined by RFC 7518 (JSON Web Algorithms).
- A JSON Web Key Set (JWKS) — the format for publishing multiple keys together, commonly at a well-known endpoint for OAuth 2.0/OpenID Connect verification — is also specified within RFC 7517.
FAQ
What's the difference between this tool and the JWT Generator?
The JWT Generator (in the Authentication hub) builds a complete signed token. This tool builds the key material — in JWK's JSON format — that a token's signature might be verified against. They're complementary: a JWK is what a verifier uses to check a JWT's signature.
Why do RSA and EC JWKs have completely different fields?
The fields directly reflect each algorithm's underlying mathematics — RSA keys are described by a modulus and exponent (n, e), while elliptic curve keys are described by a named curve and a point on it (crv, x, y). Neither format works for the other algorithm's key type.
What is the kid field for?
It's a key ID, letting a verifier pick the correct key out of a set (a JWKS) when more than one key is published — essential for supporting key rotation without breaking verification of tokens signed with the previous key during the transition.
Should I use RSA or EC for a new JWK?
EC (such as ES256) is generally preferable for new systems — it achieves comparable security to RSA at much smaller key and signature sizes, which matters for token size and verification speed, provided your libraries and consumers support it.
Is a generated JWK safe to publish?
Only the public-key fields should ever be published in a JWKS. If this tool's output includes any private-key-equivalent material, treat it as a test artifact only — production signing keys should be managed by a real key management system, not generated in a browser.
Can I convert a JWK to PEM format?
Yes — use the JWK ↔ PEM Converter to translate between the two, for libraries or services that expect one format specifically.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools