RSA encryption online refers to creating a public and private key pair directly in the browser so that one party can encrypt data with the public key and only the holder of the matching private key can decrypt it. The asymmetric pair consists of two large primes combined into a modulus of either 2048 or 3072 bits, plus a public exponent fixed at 65537, and the resulting keys are exported as standard PEM envelopes — the public key as SubjectPublicKeyInfo (SPKI) and the private key as PKCS#8 — both formatted under RFC 7468. With a browser-based RSA Key Generator, all of the math and PEM encoding happens locally in the tab through the platform Web Cryptography implementation, so no key bytes ever travel to a remote service. The output is then ready to feed into any application, service, or library that expects RSA-OAEP encryption with SHA-256.
Most readers who search for "RSA encryption online" want a working key pair they can paste into another system — a developer wiring up an API, a security engineer distributing keys to partners, or a learner verifying how asymmetric encryption flows. The rest of this article walks through what the browser actually generates, how to choose between 2048 and 3072 bits, how to run the generation step, and how to validate the result before relying on it.
How RSA Key Pairs Are Created in the Browser
The generator asks the Web Crypto API to call generateKey with the RSA-OAEP algorithm, SHA-256 as the hash, a modulus length you pick (2048 or 3072), and the public exponent 65537. Web Crypto then produces two random large primes internally, derives the modulus, computes the related private exponent, and hands back an extractable key pair object. Neither the primes nor the resulting private bytes ever leave the browser tab unless you copy them yourself, and the operation is asynchronous so a slow 3072-bit generation cannot be overwritten by a later click with smaller settings.
Because RSA security depends on unpredictable primes, the platform's cryptographically secure random source is asked for every prime. That is why the output of "Generate" is different every time, even with identical settings — a fixed private-key value would mean the key is no longer private. If you ever regenerate and the output looks identical to a previous run, treat that as a serious bug and stop using the tool.
Once the keys exist, the generator exports the public key as DER bytes in SubjectPublicKeyInfo format and the private key as DER bytes in PKCS#8 format, then wraps each in Base64 lines of 64 characters with the standard BEGIN PUBLIC KEY and BEGIN PRIVATE KEY headers described in RFC 7468. You get two text blocks you can paste anywhere a PEM is accepted.
Choosing Between 2048-Bit and 3072-Bit Moduli
RSA security scales with the modulus size, but so does the cost. The generator deliberately offers only two values — 2048 and 3072 — because they cover almost every practical encryption use case without inviting accidental 1024-bit deployments. The table below summarizes the real tradeoffs at the time of generation.
| Aspect | 2048-bit modulus | 3072-bit modulus |
|---|---|---|
| Modulus length | 2048 bits (256 bytes) | 3072 bits (384 bytes) |
| Generation time | Faster | Noticeably slower — the browser must find two larger primes |
| Encryption and decryption cost | Lower CPU per operation | Higher CPU per operation |
| Interoperability | Broadly supported by every modern RSA-OAEP stack | Supported by modern stacks; some legacy systems may reject it |
| Relative security margin | Standard | Larger |
| Best choice when | You need maximum compatibility or you generate many keys | The data must stay confidential longer and you can afford the slower path |
For most "RSA encryption online" workflows — encrypting a small payload, wrapping a symmetric key, or wiring up an application integration — 2048 bits is the right default. Pick 3072 only when the receiving system is known to accept it and you specifically want the larger security margin.
Generate an RSA Key Pair for Online Encryption
Before you click anything, confirm the application or library you plan to feed the keys into actually expects RSA-OAEP with SHA-256 and either SPKI public or PKCS#8 private PEM. A mismatch here is the most common reason an otherwise-correct key fails to import downstream. Once that is confirmed, the generation itself is short.
- Open the RSA Key Generator in a browser you trust on a patched device.
- Select 2048 bits for broad compatibility, or 3072 bits if you specifically want the stronger modulus and your consumer supports it.
- Click Generate and wait for the operation to complete; 3072-bit generation takes noticeably longer because the browser has to find two larger primes.
- Copy the public PEM block (it starts with BEGIN PUBLIC KEY) and send it only to systems that will encrypt for you.
- Copy the private PEM block (it starts with BEGIN PRIVATE KEY) directly into a protected keystore or secret manager — do not paste it into chat, source control, screenshots, or notes.
- Close the tab and clear your clipboard history once the private PEM is safely stored.
- Run an end-to-end encryption test with the receiving system using a known plaintext and confirm the decrypted result matches byte for byte.
PEM Output: SPKI for the Public Key, PKCS#8 for the Private Key
Two PEM envelopes are involved because they serve different audiences. The public key is wrapped as SubjectPublicKeyInfo, which embeds the algorithm identifier for RSA-OAEP, the modulus, and the exponent in a single ASN.1 structure. Any consumer that knows RSA-OAEP can parse this without further hints. The private key is wrapped as PKCS#8, which embeds the same algorithm identifier plus the private exponent and related parameters needed to decrypt.
Both envelopes declare the algorithm parameters as RSA-OAEP with SHA-256, so a careful consumer can read the algorithm straight from the PEM. That declaration is not decorative: if another system defaults to PKCS#1 v1.5 padding or to SHA-1, it can still accept the keys for import but will fail on the actual encryption call. A successful import is therefore not proof of compatibility — you need the round-trip test described below.
Distribute the Public Key and Protect the Private Key
The public key is designed to be shared. Anyone holding it can encrypt data that only your private key can decrypt, but they cannot use it to recover anything from a past or future ciphertext without the private key. Treat the public key like a lock — anyone can place a message into the box, only you have the key to open it.
The private key is the opposite. Anyone who obtains it can decrypt every ciphertext addressed to it, past and future, until you rotate. The generator exports it as unencrypted PKCS#8 — there is no password envelope applied by the browser. That is by design: Web Crypto hands you raw bytes and the protection happens at the storage layer. Move it immediately into a hardware-backed keystore, a cloud secret manager, or an encrypted local store with strict access control and backups. Do not commit it, paste it into tickets, paste it into chat, or leave it in browser sync.
If the private key is ever exposed — even briefly — rotate immediately: generate a new pair, distribute the new public key, and stop accepting ciphertext encrypted to the old one.
Run an End-to-End Encryption Test Before You Trust It
The single biggest source of "my RSA keys do not work" complaints is that a PEM imported successfully but the algorithm parameters were wrong on one side. The generator proves correctness by encrypting a known UTF-8 message with the public key and asserting exact recovery with the private key, then importing both PEMs back into Web Crypto and confirming the imported algorithm reports the expected modulus length. You should do the same with the receiving system.
Encrypt a small, fixed plaintext (for example the string RSA encryption online round trip) with the public key on the receiving side, send the ciphertext back, and decrypt it with the private key. If the recovered bytes match exactly and decode as the original UTF-8 string, both sides agree on RSA-OAEP, SHA-256, label, and mask generation. If anything differs, fix the parameters before relying on the key for production traffic.
What RSA Encryption Online Cannot Do
RSA can only encrypt messages that are small relative to the modulus. The maximum plaintext size for RSA-OAEP is the modulus length in bytes minus twice the hash output length minus two, defined in RFC 8017. For 2048-bit SHA-256 the substitution is 256 − (2 × 32) − 2 = 190 bytes; for 3072-bit SHA-256 it is 384 − (2 × 32) − 2 = 318 bytes. Real systems therefore encrypt a small random symmetric key with RSA-OAEP and protect the actual data with authenticated symmetric encryption, a pattern you can implement alongside this generator using a tool like the AES Encryption Online page. Do not split a large file into raw RSA blocks; the tool intentionally does not invent a hybrid file format, and a hand-rolled splitter is exactly where padding-oracle attacks begin.
This generator also is not a certificate authority. It produces RSA-OAEP encryption keys only — no X.509 certificates, no CSRs, no signatures (RSA-PSS), no SSH keys, and no JSON Web Keys. If you need identity or TLS, use the key-generation workflow provided by the owning platform or a hardware security module instead.
The table below summarizes what the tool does and does not expose, so you can verify the limits before depending on a key for real traffic.
| Capability | Available in this tool |
|---|---|
| RSA-OAEP encryption key pair generation | Yes |
| 2048-bit and 3072-bit moduli | Yes |
| Public exponent 65537 only | Fixed by design |
| SHA-256 hash, RSA-OAEP padding | Fixed by design |
| SPKI PEM public key, PKCS#8 PEM private key | Yes |
| Round-trip encryption and decryption verification at generation | Yes |
| 1024-bit modulus or custom public exponent | No |
| RSA-PKCS#1 v1.5 padding or raw RSA | No |
| Password-encrypted private key envelope | No — move bytes into your own keystore |
| RSA-PSS signatures, X.509, CSRs, SSH keys, JWK | No |
| Large-file splitter or hybrid file container | No — encrypt a key, not the file |
The implementation is fixed in safe defaults for the same reason: no 1024-bit keys, no custom public exponents, no raw RSA, no PKCS#1 v1.5 encryption, and no SHA-1. Restricting these choices reduces the chance of producing a key that works today but leaks tomorrow, and keeps the verification tests straightforward.
If you're weighing options, AES Encryption Online on Android: Browser Walkthrough covers this in detail.