What an RSA key pair is
An RSA key pair is built from two large prime numbers. Their product, the modulus n, is public, along with a public exponent e that is almost always 65537. The private key holds the primes and a derived private exponent d. The security of the scheme rests on the practical difficulty of recovering those primes from n alone, which is why key size is quoted as the bit length of the modulus.
This tool uses the browser's Web Crypto API, calling crypto.subtle.generateKey with the RSA-OAEP algorithm, SHA-256 as the hash, a public exponent of 65537, and a modulus length of 2048, 3072 or 4096 bits as you select. Web Crypto uses the platform's cryptographically secure random source, so the primes come from the operating system's entropy pool rather than from JavaScript's Math.random.
One consequence of the algorithm choice is worth stating: this pair is generated for encryption and decryption under RSA-OAEP, not for signing. Web Crypto binds an algorithm and a set of usages to a key at creation time. The exported PEM files are structurally ordinary RSA keys, but tools that expect a signing key may object, and reusing one key pair for both encryption and signatures is discouraged practice regardless.
Reading the PEM output: SPKI and PKCS#8
The public key is exported in SPKI form and wrapped as BEGIN PUBLIC KEY. SubjectPublicKeyInfo is the structure that pairs an algorithm identifier with the key bits, and it is the same structure embedded in an X.509 certificate. The private key is exported in PKCS#8 form and wrapped as BEGIN PRIVATE KEY, which similarly carries an algorithm identifier alongside the key material.
These labels matter when you paste a key somewhere. BEGIN RSA PRIVATE KEY denotes the older PKCS#1 format, which holds the RSA parameters directly with no algorithm identifier, and some tooling accepts only one of the two. Converting between them is a one-line openssl command, but reading the header first saves a confusing error.
The PEM body itself is base64 of the DER bytes, wrapped at 64 characters. That means the file is plain text and can be transported anywhere text can go, and it also means the private key is not protected in any way by the encoding. A PKCS#8 private key can be encrypted under a passphrase, producing a BEGIN ENCRYPTED PRIVATE KEY block; the keys generated here are not encrypted.
A key generated in a browser should not protect anything of value
The randomness here is sound, but the environment is not a suitable place to create a key you intend to rely on. The private key exists as a string in the page's JavaScript memory, is rendered into the DOM where it can be read by anything running in the page, and is typically moved onward through the system clipboard. Any browser extension with access to page content, any injected script, and any clipboard manager can see it.
It is also not stored anywhere. Nothing is saved, so the key exists only until you navigate away, which makes it easy to lose and impossible to audit. There is no passphrase protection, no hardware backing, no key attestation and no record of when or where it was created, all of which real key management depends on.
Generate production keys where they will live and with tooling built for it: ssh-keygen -t ed25519 for SSH access, openssl genpkey or a certificate authority workflow for TLS, a cloud key management service or a hardware security module for anything that must not be extractable. Use this tool for learning how the formats look, for local experiments, and for throwaway test fixtures, and treat every key it produces as compromised the moment it is created.
Choosing a key size, and what RSA can actually encrypt
2048 bits is the current baseline and is widely considered adequate for use through the end of this decade; 3072 bits is the conservative choice for longer-lived keys and corresponds roughly to a 128-bit symmetric security level. 4096 bits buys a modest amount of additional margin at a real cost: key generation can take several seconds in a browser, and every private key operation is meaningfully slower.
For new systems, elliptic curve keys are usually the better answer. Ed25519 or an ECDSA key on the P-256 curve gives comparable or better security than 3072-bit RSA with keys that are a fraction of the size and operations that are far faster. RSA persists mainly for compatibility with existing infrastructure.
RSA also cannot encrypt bulk data. Under OAEP with SHA-256, a 2048-bit key can encrypt at most 190 bytes in one operation, and a 4096-bit key at most 446. Real systems therefore use hybrid encryption: generate a random symmetric key, encrypt the data with AES-GCM, and use RSA only to encrypt that symmetric key. Anyone attempting to feed a file directly into an RSA operation has hit the wrong tool for the job.