RSA Key Pair Generator Online — 2048/3072/4096, PEM & JWK

No. Key generation runs entirely in your browser via the Web Crypto API's crypto.subtle.generateKey(). You can verify with your browser's DevTools Network panel — no request is made when you click Generate. The private key exists only in this tab's memory and is destroyed when you close it.

2048 bits is the modern minimum and is still fine for most use cases. 3072 bits is what NIST recommends for anything expected to be secure past 2030. 4096 bits provides an extra safety margin but is roughly 5× slower for private-key operations. If you're targeting a device with limited CPU (embedded, mobile), stick with 2048; for long-lived server keys, 3072 is a sensible default.

RSA-OAEP is used for encryption (encrypting a symmetric key, for example). RSA-PSS is the modern padding for signatures with proper security proofs. RSASSA-PKCS1-v1_5 is the older signature padding still required for RS256 JWTs, TLS 1.2 signing, and many legacy protocols. Pick based on what your target system expects.

PKCS#8 is the IETF standard container format for asymmetric private keys, defined in RFC 5208 / 5958. OpenSSL's older '-----BEGIN RSA PRIVATE KEY-----' header is PKCS#1 (RSA-specific). Node, Go's crypto/x509, Java's KeyFactory, and modern Python cryptography all prefer PKCS#8 because it's algorithm-agnostic. If a legacy tool needs PKCS#1, run `openssl rsa -in key.pem -traditional` to convert.

Yes. For RS256 JWTs, pick RSASSA-PKCS1-v1_5 with SHA-256. For PS256 JWTs, pick RSA-PSS with SHA-256. Copy the private key PEM into your JWT library (jsonwebtoken, PyJWT, jose, etc.) and it'll sign against it directly. The public key JWK from this tool can be published as a JWKS endpoint for verifiers.

For personal / development use, yes — this tool is convenient and safe. For production keys that protect real assets, generate them inside a Hardware Security Module (HSM) or Cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) so the private key never exists on any general-purpose computer.