To generate an RSA key pair in Windows without installing OpenSSL or PuTTYgen, open a browser-based generator like RSA Key Generator and produce a fresh RSA-OAEP key pair with a 2048- or 3072-bit modulus, exponent 65537, and SHA-256 hashing, then export the public key as SubjectPublicKeyInfo (SPKI) PEM and the private key as PKCS#8 PEM. The whole flow stays inside your local browser tab, so there is no OpenSSL binary download, no PATH edits, and no extra executable on disk. You still get industry-standard PEM envelopes that drop straight into any application expecting RSA-OAEP encryption with SHA-256. Because the keys are created by the Web Cryptography API inside the same tab where you started, the raw bytes never travel to a remote server, which keeps the private half out of the public internet. From there you copy the public PEM to whoever needs to encrypt for you and import the private PEM directly into a protected Windows keystore or secret manager without leaving plaintext sitting in chat, tickets, or source control.
That last point matters because RSA private keys are not recoverable if you lose them after distribution. Anyone holding the private PEM can decrypt every ciphertext produced for the matching public key, so the workflow around the generator is as important as the click that creates the keys.
Confirm What the Receiving Application Expects
Before you click generate, check three things in the application's documentation or developer guide. First, confirm it actually wants RSA-OAEP with SHA-256 as the encryption scheme, because RSA-OAEP with SHA-1, raw textbook RSA, and RSA-PKCS1-v1_5 padding are all different algorithms and the keys you produce here will not interoperate with the wrong choice. Second, confirm the expected public-key envelope is SPKI PEM, which is the block that begins with BEGIN PUBLIC KEY, and the expected private-key envelope is unencrypted PKCS#8 PEM, which is the block that begins with BEGIN PRIVATE KEY. Some legacy systems want PKCS#1 PEM with BEGIN RSA PRIVATE KEY headers, and that format is outside what this browser generator emits. Third, confirm the modulus size it accepts: most modern stacks support 2048 and 3072 bits, but a few older libraries hard-cap at 2048.
If the target application expects a certificate, CSR, SSH key, or signature key, this is the wrong tool. The generator produces encryption keys only and explicitly does not create X.509 certificates, signing keys, or SSH credentials. For TLS server identity or document signatures, use the platform's own key-generation workflow or a hardware security module instead.
Generate the RSA Key Pair in Your Browser
- Open the RSA Key Generator page in a current Edge, Chrome, or Firefox tab on your Windows machine.
- Pick 2048 or 3072 bits. Use 2048 when interoperability is the priority; use 3072 when the consumer accepts the larger modulus and you want a wider security margin.
- Click the generate button. The page asks the browser's Web Cryptography implementation to produce two large primes and combine them with the public exponent 65537, then exports the public half as SPKI DER and the private half as PKCS#8 DER.
- Wait for the operation to finish. A 3072-bit key takes noticeably longer than 2048 bits because the browser must find larger primes. Generation is asynchronous, so the tab stays responsive while the key material is being produced.
- Verify the public PEM header reads -----BEGIN PUBLIC KEY----- and the private PEM header reads -----BEGIN PRIVATE KEY-----. If the headers look different, regenerate rather than reusing the output.
The output is intentionally random. Generating twice with identical settings must produce different keys, because secure RSA requires unique primes on every run. Do not treat the output as deterministic and do not try to seed it to a fixed value.
2048 vs 3072 Bits at a Glance
| Property | 2048-bit RSA-OAEP | 3072-bit RSA-OAEP |
|---|---|---|
| Generation time in browser | Fast | Slower generation and operations |
| Interoperability | Broadly supported | Widely supported but some older libraries refuse it |
| Security margin | Standard for current applications | Larger margin against future factoring improvements |
| Maximum plaintext per RSA block (SHA-256) | Limited, smaller than 3072 | Slightly larger than 2048 |
| Recommended when | The consumer is a legacy or strict stack | The consumer is modern and you want extra safety |
RSA encrypts only a small payload per operation. Applications almost always encrypt a random symmetric key with RSA-OAEP and then protect the actual file or message with authenticated symmetric encryption such as AES-GCM. Do not split a large file into raw RSA blocks, and do not rely on this page for hybrid file formats.
Distribute the Public Key and Import the Private Key
Copy only the BEGIN PUBLIC KEY block to systems or people who need to encrypt for you. The public PEM can travel by email, ticket, chat, or web form without exposing anything secret, because the public key cannot be used to recover ciphertext meant for the holder. The private PEM is the opposite: anyone who gets it can decrypt everything encrypted for that public key, so the moment it is on your screen it is fully exposed.
Move the private PEM directly into a protected Windows location. Suitable targets include:
- The Windows certificate store for the current user, imported via the Certificates MMC snap-in (certmgr.msc).
- A managed secret store such as Azure Key Vault, HashiCorp Vault, or a Windows DPAPI-protected file.
- An HSM-backed keystore if your organization has one.
Avoid storing the private PEM in plain text on disk, in Git repositories, in chat logs, in screenshots, or in browser sync. If any of those already happened, rotate the key immediately and reissue a new pair.
The private key output from this generator is not password-encrypted. It is plain PKCS#8 bytes wrapped in a PEM envelope, so the protection comes entirely from where you store it, not from an embedded passphrase. If you need a password-protected copy, encrypt the PEM with a separate symmetric tool after import.
Run an End-to-End Encryption Test on Windows
A PEM that imports successfully is not enough proof that the parameters match. Many libraries will accept a key but silently fall back to SHA-1, ignore the OAEP label, or use PKCS#1 v1.5 padding, and the failure only shows up when decryption returns garbage or throws a padding error. The product contract for this generator is locked to RSA-OAEP with SHA-256, so to confirm the consumer actually agrees, perform a protocol-level round trip.
- Have the receiving side load the public PEM you copied.
- Encrypt a known UTF-8 string such as rsa-oaep round trip 2025 with the public key.
- Send the ciphertext back to the private-key holder.
- Decrypt with the private key and compare the recovered bytes to the original string character for character.
If the recovered plaintext matches, the algorithms, padding, label, and modulus size all agree and you can trust the pair in production. If decryption throws, the most likely culprits are SHA-1 versus SHA-256 mismatch, OAEP label mismatch, or a modulus size the consumer does not accept.
What This Browser Generator Will and Will Not Do
| Capability | Supported by this tool |
|---|---|
| RSA-OAEP encryption keys, 2048 or 3072 bits | Yes |
| Public exponent locked to 65537 | Yes |
| SHA-256 hash for OAEP | Yes |
| SPKI PEM public key output | Yes |
| PKCS#8 PEM private key output | Yes, unencrypted |
| 1024-bit or smaller keys | No |
| Custom public exponent | No |
| Raw RSA or PKCS#1 v1.5 padding | No |
| RSA-PSS signatures, X.509 certificates, CSRs, SSH keys, JWKs | No |
| Password-encrypted private PEM | No, encrypt separately |
| Uploading key bytes to a server | No, generation stays in the tab |
The fixed-parameter design is deliberate. By offering only safe defaults, the generator removes the most common configuration mistakes that lead to weak keys or wrong padding, which is the more frequent failure mode than brute-forcing the modulus. If you need a key for any purpose other than RSA-OAEP encryption with SHA-256 and either 2048 or 3072 bits, use a different tool that targets that exact scheme.
Operational Notes for Windows Users
The Web Cryptography implementation in modern Windows browsers does the actual prime generation, so the quality of randomness matches what your Edge or Chrome profile already uses for TLS and WebAuthn. That said, browser extensions, clipboard managers, screenshots, malware on the host, and remote-desktop session recording all sit outside the browser's guarantee, so run the generator on a trusted, fully patched Windows device with no untrusted extensions installed. Close the tab as soon as you have imported the private key into a protected store, and clear your clipboard history so the PEM does not linger in Win+V.
When the consumer is on a different operating system, the algorithm compatibility rules from RFC 8017 still apply. The envelope rules from RFC 7468 govern the BEGIN PUBLIC KEY and BEGIN PRIVATE KEY headers you see, which is why those exact strings are the right thing to look for when you verify the output.
For the equivalent workflow on Linux without OpenSSL, see the related guide on generating an RSA key pair in Linux without OpenSSL, which uses the same browser generator but discusses the Linux-side import paths.