The private key produced here is generated in your browser and exists nowhere else. Reload the page and it is gone permanently. Save it before you navigate away.
RSA or elliptic curve
For anything new, elliptic curve. P-256 gives roughly the same security as RSA-3072 with keys an order of magnitude smaller and signing operations that are dramatically faster.
| Algorithm | Security level | Public key size |
|---|---|---|
| RSA-2048 | ~112 bits | ~294 bytes |
| RSA-3072 | ~128 bits | ~422 bytes |
| RSA-4096 | ~152 bits | ~550 bytes |
| EC P-256 | ~128 bits | ~91 bytes |
| EC P-384 | ~192 bits | ~120 bytes |
| EC P-521 | ~256 bits | ~158 bytes |
RSA-2048 provides about 112 bits, which NIST has scheduled for retirement by 2030. It remains the most widely compatible choice and is fine for existing systems; do not choose it for something new.
The reason to still use RSA is compatibility. Some older systems, hardware modules and enterprise integrations accept nothing else.
Signing or encryption
The purpose selector changes the algorithm, and the distinction matters:
- Sign and verify produces RSASSA-PKCS1-v1_5 or ECDSA keys. Use for JWTs, code signing, and anything proving authorship.
- Encrypt and decrypt produces RSA-OAEP or ECDH keys. Use for protecting data with a public key.
A key generated for one is not usable for the other, which is deliberate: reusing a key across purposes weakens both.
Output formats
Public key, SPKI PEM. The standard BEGIN PUBLIC KEY block. Distribute freely — it can verify but not sign.
Private key, PKCS#8 PEM. The BEGIN PRIVATE KEY block. This is the secret half. Anyone with it can impersonate you.
Public JWK. JSON Web Key form, for a JWKS endpoint. Add a kid and this drops straight into /.well-known/jwks.json so JWT verifiers can fetch your key. The JWT decoder consumes the PEM form of the same key.
RSA-4096 is usually the wrong instinct
The reasoning "bigger is safer" leads people to 4096 by default. What it actually buys is roughly 24 bits of security over 3072, at the cost of signing operations several times slower and keys nearly twice as large. If RSA-3072 is not enough for your threat model, the answer is EC P-384, not a larger modulus.
Frequently asked questions
Is it safe to generate a production key in a browser?
The generation itself uses the same platform primitives a server would. The genuine risks are your device and what you do next: a compromised machine or extension sees the key, and the key exists in browser memory until you close the tab. For a production signing key, generating on a hardened server or in an HSM remains better practice.
What is the difference between PKCS#8 and PKCS#1?
PKCS#1 (BEGIN RSA PRIVATE KEY) is RSA-specific. PKCS#8 (BEGIN PRIVATE KEY) is a general container that works for RSA, EC and others. Web Crypto exports PKCS#8. Convert with openssl rsa -in key.pem -traditional if a tool requires PKCS#1.
Can I get an encrypted private key?
Not from Web Crypto — it exports unencrypted PKCS#8. Encrypt it yourself with openssl pkcs8 -topk8 -v2 aes-256-cbc, or with the AES encryption tool if you only need it protected at rest.
Which curve should I choose?
P-256 unless you have a reason otherwise. It is the most widely supported, fast, and provides 128-bit security. P-384 for higher assurance requirements. P-521 is rarely necessary and less broadly supported.