To create an RSA key in your browser without installing ssh-keygen, RSA Key Generator produces a 2048- or 3072-bit RSA-OAEP key pair with SHA-256 using the platform's Web Cryptography API, then exports the public key as SubjectPublicKeyInfo (SPKI) PEM and the private key as unencrypted PKCS#8 PEM. Generation runs entirely in the current tab through RSA Key Generator, so no key material is sent to a remote server, and every freshly generated pair is different even with identical settings because the underlying random number generator produces two new large primes each run. The fixed parameters, RSA-OAEP, SHA-256, exponent 65537, and the standard PEM envelopes, make the output drop-in compatible with systems that expect those exact choices, but they also make the output unsuitable for one specific common job: SSH authentication. A successful import is not proof of protocol compatibility, because OAEP's hash, label, and mask-generation function all have to match on the decrypting side, and a different consumer that defaults to SHA-1 or to a non-empty OAEP label will fail in ways that surface only when production traffic depends on the key.
What RSA Key Generator Actually Produces
RSA Key Generator is built around a small set of fixed choices that the surrounding code does not expose: the algorithm is RSA-OAEP rather than raw RSA or PKCS#1 v1.5 padding, the hash is SHA-256 rather than SHA-1, and the public exponent is the standard 65537. You select a modulus size of 2048 or 3072 bits and the page calls Web Crypto's generateKey, which creates two large primes and the resulting modulus without any deterministic seed. The keys are returned as extractable CryptoKey objects, exported to DER bytes (SPKI for public, PKCS#8 for private), and wrapped with the standard PEM headers as defined in RFC 7468. The public envelope begins with -----BEGIN PUBLIC KEY----- and the private envelope with -----BEGIN PRIVATE KEY-----, and the Base64 body is wrapped at 64 columns for readable copy and paste.
The page deliberately omits several adjacent options. It does not generate 1024-bit keys, does not allow a custom public exponent, does not produce raw RSA ciphertext, does not encrypt the private PEM with a passphrase, does not emit PKCS#1 v1.5 envelopes, and does not default to SHA-1. It also does not produce OpenSSH key files, X.509 certificates, certificate signing requests, RSA-PSS signing keys, or JSON Web Keys. Those omissions are intentional: the tool's purpose is to remove easy footguns when someone needs a quick RSA-OAEP encryption key pair, not to be a general-purpose cryptography workshop.
SSH Keys vs RSA-OAEP PEM Keys: An Honest Distinction
Most people who search for a way to create an RSA key for SSH actually want a key that authenticates them when they log in to a remote server with OpenSSH. SSH authentication uses a different file format, traditionally an OpenSSH proprietary envelope that begins with -----BEGIN OPENSSH PRIVATE KEY-----, generated by the ssh-keygen utility or a comparable client. That envelope embeds the algorithm name, a comment field, and a binary blob that OpenSSH parses on its own. Even when the underlying RSA math is similar, the surrounding wire format is not.
RSA Key Generator outputs standard PEM envelopes (SPKI for the public side, PKCS#8 for the private side) with RSA-OAEP and SHA-256. Those are the right choices for general RSA encryption APIs, code that consumes PEM directly, hybrid encryption schemes that wrap a symmetric key, and any application that imports SubjectPublicKeyInfo and unwraps PrivateKeyInfo. They are not the right format for OpenSSH's authorized_keys and id_rsa pipeline. If your goal is to drop a key into ~/.ssh/authorized_keys or to load it in PuTTY, this tool will not produce the right file. Use ssh-keygen -t rsa -b 3072, or a platform-specific helper, instead.
The overlap is narrower than it looks. Both tools deal with RSA modulus sizes of 2048 or 3072 bits, both default to exponent 65537, and both rely on a strong random number generator. The differences are the algorithm role (authentication signature for SSH versus OAEP encryption for this tool), the hash binding inside the file, the label and mask-generation defaults, and the storage format. Treat them as two distinct deliverables rather than two flavors of the same artifact.
| Property | OpenSSH RSA key (ssh-keygen) | RSA Key Generator output |
|---|---|---|
| File envelope | OpenSSH proprietary, begins BEGIN OPENSSH PRIVATE KEY | SPKI for public, PKCS#8 for private, standard PEM |
| Algorithm role | Authentication signature | RSA-OAEP encryption |
| Hash binding | SHA-1 in older versions, SHA-256 or SHA-512 in newer | SHA-256 fixed |
| Public exponent | 65537 | 65537 |
| Typical sizes | 2048, 3072, 4096 bits | 2048 or 3072 bits |
| Passphrase on private file | Optional | Not supported, exported as unencrypted PKCS#8 |
| Suitable for ssh authorized_keys | Yes | No |
| Suitable for RSA-OAEP encryption APIs | Only with extra conversion | Yes |
How to Create an RSA Key Pair Step by Step
- Confirm what your consumer expects. Before generating anything, verify that the target application actually wants RSA-OAEP with SHA-256, exponent 65537, SPKI on the public side and PKCS#8 on the private side. If the consumer is OpenSSH, stop and use ssh-keygen instead. If the consumer is an API or library that imports PEM, continue.
- Pick a modulus size. Choose 2048 bits for broad interoperability and faster generation, or 3072 bits for a larger security margin with slower generation and slower encryption operations. There is no 1024-bit option, no custom exponent, and no way to change the hash.
- Open the RSA Key Generator page on a trusted, patched device. Generation runs in the browser tab, so avoid shared computers, public kiosks, and devices with screen-sharing or remote-management software active.
- Generate the key pair. Trigger the generation action and wait. Larger keys take noticeably more time because Web Crypto has to search for two large primes; do not interrupt the tab, refresh the page, or navigate away mid-generation.
- Copy the public key to the consumer. The public block begins with -----BEGIN PUBLIC KEY----- and is safe to share with anyone who needs to encrypt for you. It is also safe to commit it to version control or paste it into a ticket.
- Move the private key directly into protected storage. The private block begins with -----BEGIN PRIVATE KEY----- and is not password-protected. Paste it straight into a hardware-backed keystore, a managed secret store, or an encrypted file with strict access control. Do not save it to ordinary notes, chat logs, browser sync, or source control.
- Close the tab and clear your clipboard history. Once the private key is safely stored, the page no longer needs the values, and a clipboard manager could otherwise retain the bytes long after you close the window.
Choosing Between 2048-Bit and 3072-Bit Moduli
The two offered sizes cover the realistic range for browser-side generation. 2048 bits is the de facto interoperable size: libraries on almost every platform import it, encryption and decryption round-trip at acceptable speed, and the security margin is still considered adequate for non-long-term secrets. 3072 bits provides a larger security margin that matters when the protected data retains sensitivity for years, but generation and RSA operations are slower in Web Crypto. If you only need a one-time wrap key for a hybrid scheme, 2048 is the practical default. If the same key will protect a long-lived master secret, prefer 3072.
There is no 1024-bit option because that size is below current safe-use thresholds and would weaken the very guarantee the tool aims to provide. The two offered sizes cover the realistic browser generation range, and any choice beyond them shifts the cost-benefit calculation toward server-side or hardware-based generation.
Distributing the Public Key and Securing the Private Key
Once a key pair exists, the practical job splits into two halves. The public SPKI envelope can be sent through any channel that needs to encrypt for the holder: it can be mailed, posted in a ticket, committed to a repository, or shared via a signed URL. It cannot decrypt anything and it cannot sign anything under RSA-OAEP, so disclosure has limited impact beyond the obvious, namely that someone can encrypt data that only the holder's private key can later decrypt.
The PKCS#8 private envelope is the dangerous half. Anyone who obtains it can decrypt every ciphertext that was encrypted for the corresponding public key, so copying it transfers full responsibility for its protection. The output is not password-protected; Web Crypto exports the PKCS#8 bytes without an encryption envelope, and the page intentionally avoids adding a weak password-based wrapping step. Move the bytes straight into a hardware security module, a managed secret store, an encrypted file with restricted access, or an offline backup. Never store it in source control, browser sync, ordinary notes, screenshots, or chat transcripts. Rotate the key immediately if exposure is even suspected.
Running a Protocol-Level Encryption Test
The tool's own correctness check is a strict round-trip: it exports both envelopes, imports the SPKI public key and the PKCS#8 private key back into Web Crypto, encrypts a known UTF-8 message with the public key, and asserts that decryption with the private key reproduces the exact original bytes. That confirms the generated pair is internally consistent and that the parameters match what Web Crypto reports. It does not, by itself, confirm compatibility with the target application.
Perform a second test on the receiving side. Take a short test message, encrypt it with the public key using the exact library or command your application uses, and decrypt the result with the imported private key. RSA-OAEP parameters must match on both sides, including the hash, the label, and the mask-generation function, and a PEM that imports successfully is not enough on its own. If the consumer defaults to SHA-1, to a different OAEP label, or to PKCS#1 v1.5 padding, this tool's output will not interoperate. Discover that early, before any production traffic depends on the key. The PKCS#1 v2.2 specification in RFC 8017 documents exactly which parameters must match for two endpoints to agree.
When This Tool Fits and When You Need ssh-keygen
Use RSA Key Generator when you need an RSA-OAEP encryption key pair with standard PEM envelopes and you want the keys generated locally without installing OpenSSL, ssh-keygen, or any command-line tooling. The fit covers hybrid encryption schemes that wrap a random symmetric key, application-level message encryption APIs that import SPKI and PKCS#8, library code that calls into Web Crypto or any standard PEM consumer, and quick protocol experiments on a laptop.
Use ssh-keygen, or your platform's SSH helper, when you need to authenticate to a remote host, to add an entry to ~/.ssh/authorized_keys, or to load a key into PuTTY or MobaXterm. For broader guidance on running an equivalent generation in a Linux terminal without OpenSSL, the Linux-without-OpenSSL walk-through covers the same browser-based approach in a Linux workflow. For production identity, certificate authorities, or TLS server keys, use the key-generation workflow of the platform that owns those credentials, ideally backed by a hardware security module.
If the private key is ever exposed, rotate immediately. The page does not retain the key bytes beyond component memory, but extensions, malware, clipboard managers, and screenshots all sit outside that boundary, so treat any possible disclosure as a full compromise rather than a near-miss.
If you're weighing options, XOR Encryption Online: Apply a Repeating Key to UTF-8 covers this in detail.