Is the private key uploaded to a server when I generate it?

No. Web Crypto generates and exports the key pair in this tab. The tool itself does not upload key bytes, although browser extensions, malware, and clipboard managers remain outside that guarantee.

Why is the private PEM not password protected?

Web Crypto exports PKCS#8 bytes without a password envelope here. Move the private PEM immediately into a protected keystore or secret manager instead of leaving it in a file.

Can I use these keys for signatures, TLS certificates, or SSH login?

No. The generator only produces RSA-OAEP encryption keys, not RSA-PSS signatures, CSRs, X.509 certificates, or SSH keys.

Do I need to verify the consumer expects SHA-256 before generating?

Yes. If the receiving system defaults to SHA-1 or to PKCS#1 v1.5 padding, the PEM will import but the round trip will fail. Confirm parameters first and only then generate.

What is the smallest key size the tool offers?

2048 bits. Smaller moduli are intentionally not offered because they are no longer considered safe for general use.

Should I store the private PEM in source control or in a ticket?

Never. The private PEM grants decryption of any ciphertext encrypted to the matching public key, so it belongs in a secret manager, an encrypted keystore, or an HSM, not in code, tickets, chat, or notes.

RSA Key Generator Alternative for RSA-OAEP Encryption

An RSA key generator alternative built on the browser Web Crypto API produces a fresh 2048- or 3072-bit RSA-OAEP key pair with SHA-256, exponent 65537, SPKI public output, and PKCS#8 private output directly in the current tab, without invoking OpenSSL, ssh-keygen, PuTTYgen, or a remote server. RSA-OAEP is the recommended asymmetric encryption padding in PKCS#1 v2.2, and locking SHA-256 plus the public exponent 65537 removes the legacy defaults that have weakened older deployments. Because the generation goes through the platform's Web Cryptography implementation, the prime search and key assembly never leave the user's machine, although browser extensions, clipboard managers, and any background process remain outside that boundary. The exported PEM blocks follow the RFC 7468 formatting rules and can be pasted into any application that consumes RSA-OAEP public keys for encryption. Running the same settings twice returns a different key pair each time, which is the expected behavior for a random prime search. The sections below explain what the alternative replaces, how to use it, and the validation steps required before trusting the output in production.

Why a Browser-Based Generator Is a Practical Alternative

Traditional RSA key generation flows ask the user to install a toolchain. OpenSSL on Linux needs a package, ssh-keygen assumes a shell environment, PuTTYgen runs on Windows, and language libraries require a runtime plus the right binding. Each path adds friction and a version surface where defaults can drift toward unsafe choices such as 1024-bit moduli, SHA-1, or PKCS#1 v1.5 padding. A browser-based RSA Key Generator sidesteps that surface by delegating to the platform's audited Web Cryptography implementation and refusing to expose the unsafe choices in the user interface. The fixed parameter set is the feature: there is no dropdown for 1024-bit keys, no toggle for raw RSA, and no field for a custom exponent, which removes the most common misuse paths.

The same property applies to key transport. Server-side generators must be trusted with the private key bytes during the request lifecycle, and pastebin-style sites keep those bytes in memory or on disk beyond the session. A browser tool generates, exports, and renders the PEM entirely on the client side, then hands the bytes straight to the clipboard or a download action. Nothing is uploaded, which is the boundary the tool itself draws and the boundary every operator should re-verify by watching the network panel during generation.

What Parameters the Generator Locks In

The tool calls SubtleCrypto.generateKey with a fixed algorithm name, hash, modulus length, and public exponent, then wraps the resulting CryptoKey objects into PEM. Locked parameters matter because mismatched parameters are the silent cause of decryption failures between systems. The contract is narrow on purpose:

Algorithm: RSA-OAEP, defined for encryption and decryption only.
Hash: SHA-256, which disables SHA-1 collisions from interfering with OAEP label processing.
Modulus: 2048 or 3072 bits, chosen by the user before generation.
Public exponent: 65537, the F4 prime that almost every RSA library accepts.
Public envelope: SubjectPublicKeyInfo PEM, base64-wrapped ASN.1 at 64 columns per RFC 7468.
Private envelope: PKCS#8 unencrypted PEM, base64-wrapped ASN.1 at 64 columns.

Generation is asynchronous and a job identity prevents an older request from overwriting newer settings if a user changes the modulus mid-generation. The internal test harness imports the exported SPKI and PKCS#8 back into Web Crypto, encrypts a known UTF-8 message with the public key, and asserts exact recovery with the private key; if any step fails, the displayed PEM would not pass the harness, which is why round-trip testing is treated as mandatory rather than optional.

Choose a Key Size

The two supported sizes are not interchangeable for every workflow. The choice affects generation time on the browser thread, the size of the PEM blocks, and the per-operation cost on the consumer side.

Property	2048-bit	3072-bit
Modulus length	2048 bits	3072 bits
Browser generation time	Faster generation than the 3072-bit option	Slower, prime search scales super-linearly with modulus length
Interoperability	Broad, accepted by virtually every RSA consumer	Broad on modern stacks; verify legacy receivers before adopting
Security margin	Standard for current applications	Larger margin, useful for longer key retention horizons
Recommended when	Default choice for new integrations	Higher-assurance data or longer-lived ciphertext

Pick 2048 unless the application documentation or a compliance requirement specifies a larger modulus. Pick 3072 when the ciphertext lifetime exceeds a few years or when the receiving system explicitly demands it. The tool does not offer 1024-bit keys because that modulus length is no longer considered safe.

Generate a Key Pair in Your Browser

Verify the target application. Confirm that the consumer expects RSA-OAEP with SHA-256, exponent 65537, and one of the two PEM envelopes. If the application defaults to SHA-1 or to PKCS#1 v1.5 padding, the generated key will import but round-trip tests will fail.
Select a modulus length. Choose 2048 bits for broad interoperability or 3072 bits for a larger security margin. Allow extra time for 3072-bit generation on lower-powered hardware because the prime search is the dominant cost.
Run generation. Trigger the generate action. The tool invokes crypto.subtle.generateKey with the locked parameters and waits for the promise to resolve before exporting. Do not click again until the PEM blocks appear, because each click produces a new key pair and the older one is lost.
Copy the public key. Take the block that begins with -----BEGIN PUBLIC KEY----- and ends with -----END PUBLIC KEY-----. Distribute it to any system that needs to encrypt for this holder.
Import the private key directly into protected storage. Take the block that begins with -----BEGIN PRIVATE KEY----- and paste it into a secret manager, encrypted keystore, or hardware-backed store. Do not save it to disk in a development folder and do not paste it into a code review.
Close the tab and clear the clipboard. The private PEM lives in component memory only until navigation, but the clipboard still holds it until overwritten. Paste over the clipboard with unrelated text or let the operating system clear clipboard history.

Read the PEM Blocks: SPKI and PKCS#8

Two PEM headers are produced and they describe two different things. The block starting with BEGIN PUBLIC KEY contains an ASN.1 SubjectPublicKeyInfo structure: an algorithm identifier declaring RSA-OAEP with SHA-256, followed by the modulus and the public exponent 65537. This block is meant to be shared. The block starting with BEGIN PRIVATE KEY contains PKCS#8 key material: the matching private exponent, the same modulus, and the CRT parameters needed to decrypt efficiently. Anyone who obtains the private block can decrypt every ciphertext encrypted to the matching public key, so the block is treated as a secret on the same level as a database password.

Both envelopes are unencrypted. PKCS#8 supports a password-encrypted variant, but the tool deliberately exports the unencrypted form so the bytes can move directly into a downstream protected store. If a password-protected PEM is required, wrap the PKCS#8 bytes through a separate encrypted-PEM toolchain rather than re-encrypting inside the generator.

Distribute the Public Key, Protect the Private Key

Public key distribution is unrestricted: send it over email, paste it into a configuration, or commit it next to the application code that consumes it. Private key protection is the opposite. Move the private PEM into a secret manager or an HSM-backed keystore, restrict access with role-based controls, and back it up under the same controls that govern other cryptographic material. Do not put it into source control, ticketing systems, analytics, browser sync, screenshots, or ordinary notes. If the private key is exposed, rotate immediately: generate a new pair, re-distribute the new public key, and re-encrypt any data that the old private key would have unlocked.

When handing the private key to a teammate for import, prefer a short-lived out-of-band channel that does not log the payload: a direct transfer into their keystore, a password manager share, or a temporary upload to a controlled artifact registry. Audit logs and clipboard managers both retain copies of plain text far longer than the user expects.

Run an End-to-End Encryption Test

A successful import does not prove the keys are usable. The recipient system may default to a different hash, a different label, or a different mask-generation function, and OAEP will silently fail to recover plaintext under those mismatches. The only reliable check is a real round trip using the exact protocol the application will use:

Encrypt a known UTF-8 string with the public key in the target library.
Send the ciphertext through the same transport the application uses.
Decrypt with the private key in the target library and compare against the original string.

If recovery fails, the mismatch is almost always in the OAEP parameters or in the byte encoding rather than in the modulus itself. UTF-8 bytes in, identical UTF-8 bytes out, is the only acceptable outcome.

What the Generator Does Not Replace

The tool is deliberately narrow. It does not produce RSA-PSS signing keys, X.509 certificates, certificate signing requests, SSH keys, or JSON Web Keys. For SSH-style workflows, follow the PEM versus OpenSSH guidance for a browser-based alternative. For TLS or production identity, prefer the key-generation workflow provided by the owning platform or hardware security module. RSA also encrypts only limited-size messages, so applications usually encrypt a random symmetric key with RSA-OAEP and protect the actual payload with authenticated symmetric encryption; the tool does not invent a hybrid file format, and raw RSA block splitting is unsafe.

Format conversions after generation must preserve algorithm parameters and private-key secrecy. A PEM-to-JWK conversion that drops the SHA-256 declaration or that re-encodes the exponent will produce a key that imports cleanly but decrypts nothing. Re-validate after every conversion with the round-trip test above.