RSA Key Pair Generator
100% LocalGenerate RSA-OAEP or RSA-PSS key pairs in PEM format using Web Crypto API.
Hash: SHA-256 • Public exponent: 65537
Privacy note
This tool runs entirely in your browser. Your input is never uploaded, logged, or sent to AllDevToolsHub or anyone else, and it keeps working offline once the page has loaded.
How to Use RSA Key Pair Generator
Choose Key Size
Select 2048, 3072, or 4096 bits. Use 2048 for most purposes, 4096 for long-term signing.
Select Format
Choose PEM, PKCS#8, or DER output format for your use case.
Generate
Click Generate to create the key pair using the Web Crypto API.
Copy Keys
Copy the public and private keys separately. Store the private key securely.
RSA Key Pair Generator: the essentials
The RSA Key Pair Generator creates 2048- or 4096-bit RSA-OAEP (encryption) or RSA-PSS (signing) key pairs in standard PEM format directly in your browser using the Web Crypto API's SubtleCrypto.generateKey. Private key is exported as PKCS#8, public key as SPKI, the formats every modern crypto library, OpenSSL, JWT issuer, and TLS server expects. Generation, display, and download happen entirely client-side; the private key never crosses a network boundary.
Key points
- Keys are generated by `SubtleCrypto.generateKey()`, backed by BoringSSL on Chrome, NSS on Firefox, and CoreCrypto on Safari, the same C++ crypto stack that powers the browser's TLS handshake.
- Use RSA-OAEP (PKCS#1 v2.x padding) for encryption and RSA-PSS for signatures; never reuse the same key pair across both schemes, as it weakens the security proof.
- 2048-bit RSA gives ~112 bits of security and is NIST-approved through 2030; 4096-bit gives ~140 bits but private-key operations are roughly 8× slower than 2048-bit.
- Output uses PKCS#8 for the private key and SPKI for the public key (RFC 7468 PEM), the formats accepted by OpenSSL, nginx, every cloud KMS, and every modern JWT library.
When to use it
- Bootstrapping a new JWT issuer that signs tokens with RS256 or PS256, generate the key pair, install the private PEM in your secrets manager, publish the SPKI public key in a JWKS endpoint.
- Creating an air-gapped signing key for code-signing release artifacts where the private key must never touch a network and the generation host is a freshly booted laptop.
- Producing a test key pair for local development of an mTLS-protected service so engineers can simulate certificate authentication without touching the production CA.
- Generating a recipient key pair for end-to-end encrypted file exchange where the sender uses RSA-OAEP to wrap a per-message AES-256-GCM key and ship the ciphertext.
Common mistakes
- Encrypting a multi-megabyte file directly with RSA-OAEP, RSA-2048 can only encrypt 245 bytes of plaintext, so you must use hybrid encryption with an AES session key.
- Generating a 1024-bit key because some old tutorial said so; NIST deprecated 1024-bit RSA in 2013 and Chrome refuses to accept TLS certificates signed by 1024-bit CAs.
- Committing the unencrypted PKCS#8 PEM to a Git repository, even after a force-push and `git filter-repo` the key is mirrored to every clone and must be treated as compromised.
- Confusing PKCS#1 (`-----BEGIN RSA PRIVATE KEY-----`) with PKCS#8 (`-----BEGIN PRIVATE KEY-----`); some older libraries reject PKCS#8 and need `openssl rsa -traditional` to downgrade the format.
What is RSA Key Pair Generator?
Frequently Asked Questions
Technical Deep Dive
RSA Key Pair Generator
Generate RSA public/private key pairs (2048 or 4096-bit) directly in your browser using the Web Crypto API. Supports RSA-OAEP (encryption) and RSA-PSS (signing) algorithms. Exports keys in standard PEM format (PKCS#8 private, SPKI public) with SHA-256 fingerprint. Download keys as .pem files, your private key never leaves the browser.
openssl genpkey is the production path. This page mints a Web Crypto RSA pair when you need a PEM in a hurry and cannot install OpenSSL.
Generate 2048-bit RSA. You should see a PKCS#8 private PEM and an SPKI public PEM. 4096-bit is slower in the tab and rarely needed for JWT.
Private keys generated here are for fixtures and labs. Do not use them as production signing keys.
01 RSA Strength & Security Matrix
| Key Size | Symmetric Equivalent | NIST Status | Primary Use Case |
|---|---|---|---|
| 2048-bit | ~112-bit | OK until 2030 | TLS, SSH, JWT (Standard) |
| 3072-bit | ~128-bit | Secure | High-Security Identity |
| 4096-bit | ~140-bit | Ultra-Secure | Root CAs, Code Signing |
| 1024-bit | ~80-bit | Deprecated | Legacy Support Only |
02 Cryptographic Provisioning Workflow
03 When RSA Is the Right Key, and When Ed25519 Wins
RSA is 47 years old and still the most-deployed asymmetric cipher. That doesn't make it the right default for new work in 2026, the picture splits cleanly along ecosystem lines:
-
TLS / X.509 certificates → RSA-2048 (or ECDSA P-256) Every browser, every CA, every load balancer accepts it. Let's Encrypt, DigiCert, GoDaddy all support RSA-2048 by default. ECDSA P-256 is faster and produces smaller certs, but RSA is the universally safe pick when you don't know what's on the far end.
-
JWT signing (RS256) for multi-party verification → RSA When your IdP issues tokens and many services verify, RSA's public-key distribution via JWKS is the established path. Auth0, Okta, Cognito, Azure AD all default to RSA-2048. Switching to ES256/EdDSA forces every consumer to upgrade their JWT library.
-
SSH user keys → Ed25519, not RSA OpenSSH has supported Ed25519 since 6.5 (2014); every modern server accepts it. Smaller, faster, side-channel resistant.
ssh-keygen -t ed25519is the right command. RSA SSH keys exist for compatibility with ancient bastions only. -
Git commit signing → Ed25519 or GPG-Ed25519 GitHub accepts Ed25519 SSH signatures and Ed25519 GPG subkeys. Smaller fingerprint to verify by eye, faster sign step in pre-commit hooks. RSA only when your colleague's verification toolchain predates 2018.
-
Encrypting more than a few hundred bytes → not raw RSA RSA-2048-OAEP maxes out at 245 bytes of plaintext per operation. For anything larger, use hybrid encryption: RSA encrypts a random AES-256 key, AES-GCM encrypts the actual payload. Trying to "chunk" RSA over a large payload is a sign you've taken a wrong turn.
04 Worked Examples
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxK6m...
...QzKw9k5N3WyG0fXa1JpV5h4Z2cKpQ8xQIDAQAB
-----END PUBLIC KEY-----
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier -- 1.2.840.113549.1.1.1 (rsaEncryption)
subjectPublicKey BIT STRING {
modulus n -- 2048-bit integer
publicExponent -- 65537 (0x010001)
}
}The AQAB tail of the Base64 decodes to 0x010001, the public exponent e = 65537, the Fermat prime that every modern RSA library uses by default. If you see a different exponent (3, 17), you're looking at a key generated by something old or non-standard.
{
"kty": "RSA",
"use": "sig",
"alg": "RS256",
"kid": "2026-key-1",
"n": "xK6m...QzKw9k5N3WyG0fXa1JpV5h4Z2cKpQ8xQ",
"e": "AQAB"
}
https://your-issuer/.well-known/jwks.json
{ "keys": [ /* the JWK above */ ] }Consumers fetch this URL, cache the public keys (TTL via Cache-Control), and verify incoming JWTs locally. Rotation = generate a new key pair with a new kid, publish both old + new for the overlap window, then drop the old.
# Should print key metadata, no error:openssl pkey -in private.pem -text -noout | head -5
Re-derive the public key from the private:
openssl pkey -in private.pem -pubout -out derived-public.pem
Compare to the public key you copied alongside:
diff derived-public.pem public.pem && echo "match"
openssl rsa -in private.pem -traditional -out private-pkcs1.pem
Header changes from BEGIN PRIVATE KEY to BEGIN RSA PRIVATE KEY
Browser-generated keys come out PKCS#8 by default (modern, algorithm-agnostic). Some older tools, notably some Java keystores and embedded TLS stacks, still want PKCS#1. The conversion is one OpenSSL command and lossless.
05 Related Tools
Generating the key pair is step one, most use cases need a few more tools alongside it: