RSA Key Generator
Generate RSA signing keys locally and export SPKI public and PKCS #8 private PEM.
Larger moduli take more CPU. Choose the size required by the system that will import the key rather than assuming the largest option is automatically the right one.
Public key — SPKI PEM
Generated SPKI public key will appear here.
Private key — unencrypted PKCS #8 PEM
Generated PKCS #8 private key will appear here.
Exportable means the private key can leave the CryptoKey object
Generation and export happen in the current browser tab. The private key is deliberately extractable because PEM output is the purpose of the page, and the PKCS #8 block is not password-encrypted. Copying it places key material on the clipboard. Reset removes the displayed strings from page state, but it cannot promise secure erasure from JavaScript engine memory, browser history mechanisms, extensions, or clipboard history.
The browser creates a signing key pair, not a certificate
Web Crypto generates two related RSA keys. The private key can create signatures and the public key can verify them. The selected browser algorithm is RSASSA-PKCS1-v1_5 with SHA-256 and public exponent 65537.
A certificate is a separate signed structure that binds a public key to identity and policy information. A certificate signing request is separate too. Neither one is created here, and the PEM blocks do not establish trust on their own.
SPKI and PKCS #8 tell another program how the key is packaged
SPKI public key
SubjectPublicKeyInfo carries the public-key algorithm identifier and RSA public-key bytes. PEM uses the PUBLIC KEY label around the DER encoding.
PKCS #8 private key
The exported private-key structure is wrapped with the PRIVATE KEY label. It is unencrypted, unlike an ENCRYPTED PRIVATE KEY container.
SHA-256 belongs to the Web Crypto key configuration, not the PEM label
A subtle interoperability detail matters here. Web Crypto creates the in-memory keys under the RSASSA-PKCS1-v1_5 + SHA-256 configuration, but its RSA SPKI and PKCS #8 export uses the generic rsaEncryption algorithm identifier. The exported key encoding does not record a permanent “SHA-256 only” rule.
Another platform may be able to import the same RSA key material for RSA-PSS or RSA-OAEP when its API and policy allow that use. That does not mean signature padding and encryption padding are interchangeable; the receiving protocol still has to specify the correct RSA scheme.
Reference: Web Cryptography API — RSASSA-PKCS1-v1_5 export rules
Choosing 2048, 3072, or 4096 bits is a compatibility decision too
NIST SP 800-131A Rev. 2 requires an RSA modulus of at least 2048 bits for the minimum 112-bit security-strength requirement in the U.S. federal guidance it covers. That is why 1024-bit generation is not an option here. Other organizations can impose different lifetimes, algorithms, hardware limits, or profiles.
Moving from 2048 to 3072 or 4096 bits increases key size and the cost of private-key operations. Before choosing, check the protocol, certificate profile, HSM, library, or service that will consume the key. A larger modulus does not repair an incompatible signature algorithm or weak private-key storage.
Reference: NIST SP 800-131A Rev. 2
Where the exported blocks fit—and where they do not
- They can be used where software explicitly accepts an RSA SPKI public key and unencrypted PKCS #8 private key.
- They are not OpenSSH key files and do not include SSH comments or authorized-keys formatting.
- They are not X.509 certificates, certificate signing requests, JWK documents, or PKCS #12 bundles.
- The private key has no passphrase protection; encrypt it or import it into appropriate key storage before any workflow that requires protected-at-rest key material.
- Production key generation may need an HSM, KMS, audited entropy source, non-exportable key policy, rotation process, and access controls that a browser page cannot provide.
The two container standards are worth naming precisely
RFC 5280 defines the SubjectPublicKeyInfo structure used for the public export. RFC 5958 documents asymmetric private-key packages and the PKCS #8-style PRIVATE KEY textual form. RFC 7468 describes the surrounding BEGIN/END textual encoding and 64-character Base64 line wrapping.