What a JWT keypair is
A JWT is an authentication token your server hands out to logged-in users so they can prove who they are on every later request. The server signs the token with a private key, the client sends it back on each request, and any service holding the matching public key can verify the signature was real and the payload was not modified in transit.
To make all of that work you need a keypair: a private key that lives on the server doing the signing, and a public key that you share (often as a JWK document published at `/.well-known/jwks.json`) so verifiers can check the signature without ever seeing the secret.
This tool generates that keypair for any modern signing algorithm: RS256/RS384/RS512 (classic RSA), PS256 (RSA-PSS, the safer RSA variant), ES256/ES384/ES512 (elliptic curve), or EdDSA (Ed25519, the smallest and fastest). You get the keys in both PEM and JWK formats, plus a sample signed JWT you can immediately decode in the JWT decoder to see the full round trip. Generated server-side with Node's built-in `crypto`, never stored.
How to use it
- Pick an algorithm. RS256 is the default for most setups (Auth0, Okta, Keycloak, and AWS Cognito all default to it). ES256 gives much smaller tokens. EdDSA is the modern darling: smallest keys, fastest signing, simplest implementation.
- For RSA family (RS256, RS384, RS512, PS256): pick a key size. 2048-bit is the sane default. 3072-bit and 4096-bit get exponentially slower with negligible real-world security gain.
- For EC family (ES256, ES384, ES512): the curve is chosen for you automatically (P-256, P-384, P-521 respectively). These are the only curves RFC 7518 allows for each algorithm.
- For EdDSA: we always use Ed25519, the curve standardised by RFC 8037 for JWS. There are no knobs to turn here.
- Click Generate. We return: the private key in PEM, the public key in PEM, the private key as a JWK, the public key as a JWK, plus a sample signed JWT with a tiny payload (`sub: user-123`, valid for 1 hour) so you can verify end-to-end that the keys work.
- Save the private key now. We never store it. Closing this tab loses it forever. Install it on your auth server, your API gateway, or wherever you mint tokens.
- Publish the public key as a JWKS document at `https://your-domain.com/.well-known/jwks.json`. Most libraries (jose, jsonwebtoken, PyJWT, Microsoft.IdentityModel) can fetch and cache that URL automatically.
- Click Open in decoder next to the sample JWT to see the header, payload, and signature parsed live in the JWT decoder. Confirm the kid in the header matches the JWK you published.
When this is useful
Six common situations where a fresh JWT signing keypair earns its keep:
- Setting up a new auth service (Keycloak, Ory Hydra, Auth0 self-hosted, a homegrown OAuth server, an internal API gateway). You need the keypair before you can mint a single token.
- Migrating from HS256 to RS256/ES256/EdDSA. HS256 uses a shared secret which forces every verifier to hold the signing power. Asymmetric algorithms let you keep the private key on the auth server and hand the public key out freely. This is the standard upgrade path for any system that grows past one service.
- Key rotation every 3 to 12 months as a security hygiene practice. Generate a new key under a new kid, publish both keys in your JWKS, switch the signer to the new key, retire the old one after the grace period.
- Suspected key compromise. Server breach, accidental commit of the PEM to a public repo, ex-employee with key access. Generate a new keypair, rotate, revoke the old kid in JWKS, force-logout active sessions.
- Multi-issuer architectures. Each service mints its own tokens; each gets its own keypair so their compromise blast radii are independent.
- Testing and demos. Need a working JWT to test a verifier library? Generate a keypair, sign the sample, and you have a real end-to-end example in one click.
Related tools: JWT decoder (decode and inspect any JWT), DKIM keypair generator, bcrypt verify, password hash, UUID generator.