Generador de claves online

Where the key comes from

A private key is only as good as the randomness it was drawn from. The generator never makes up its own: every key comes from the browser's cryptographically secure random number generator — the operating system's, exposed as crypto.getRandomValues and used by the Web Crypto API (CSPRNG).

For RSA, ECDSA on P-256, P-384 and P-521, Ed25519 and X25519 the page asks Web Crypto to generate the key pair (crypto.subtle.generateKey) and exports it as a JWK. Web Crypto has no secp256k1, Ed448 or X448, and some browsers still lack Ed25519 and X25519; for those, the audited @noble/curves derives the public key from a secret drawn from the same generator. RSA key generation stays with Web Crypto: there is no fast, audited pure-JavaScript alternative. Symmetric secrets are random bytes of the size you choose. The page states which engine produced the key.

Every generated key is then read back through the same parser that checks pasted keys — the point must lie on its curve, the RSA parameters must agree — before any format is written.

One key, many formats

The same key is written in every form that can hold it, so you can paste it wherever it is needed:

A format a key cannot take is listed with the reason instead of being left out silently: OpenSSH has no key type for secp256k1, X25519, X448 or Ed448, and a shared secret has no PEM form. The public JWK is what you publish in a JWKS; the private formats are what your signer or server loads.

The kid: an RFC 7638 thumbprint

By default the JWK's kid is the key's RFC 7638 thumbprint: SHA-256 over the key's required members in a fixed order (crv, kty, x, y for EC; e, kty, n for RSA), base64url-encoded. The same public key always produces the same kid, so a verifier, a JWKS and a signer agree on it without coordination; RFC 9278 turns it into a URI. A shared secret gets a random kid instead, because a thumbprint of a secret is a hash of the secret itself. use is filled in from the key type — sig for signing keys, enc for X25519 and X448 — and alg can be set to the algorithm the key is usually published with.

Which key to choose

• P-256 (ES256) is supported by every JOSE library, every browser and every cloud KMS — the safe default for JWTs. ES256 vs RS256 compares it with RSA.
• Ed25519 is fast, deterministic and hard to misuse; check that every verifier you depend on accepts it.
• RSA is still the most widely accepted signing key. JOSE requires 2048 bits or more (RFC 7518 §3.3); choose 3072 bits or more for keys meant to last beyond 2030.
• secp256k1 (ES256K) is for blockchain ecosystems (RFC 8812); outside them few libraries support it.
• X25519 and X448 are for key agreement (ECDH-ES in JWE), not for signatures.
• Secrets of 256 bits or more are HMAC keys for HS256 and up (RFC 7518 §3.2 asks for at least the hash length); 128- and 192-bit secrets are AES key-wrapping keys.

Why generate in the browser

A private key should be created where it is going to live and travel as little as possible. Here it is created in the page's memory and nowhere else: the generator makes no network request, and a share link carries only the settings, so whoever opens it generates a key of their own. Copy the private key straight into a password manager, a secrets vault or your deployment, and publish only the public half — for example with the JWKS builder. To sign a test token with the new key, open the JWT signer.