← All Tools
Private RSA Key Generator🔒 100% local
Generate key pairs. Privacy-first, no server uploads, no tracking.
Related Tools
Guidance and inspection rather than generation, despite the name. Paste a PEM block, a JWK or an ssh-rsa/ssh-ed25519 public key and the page names the format, explains the header, counts base64 characters to estimate the DER size, estimates a JWK modulus in bits and lists findings. Type a bit size instead and it prints the equivalent symmetric strength, a warning and the openssl and Node commands to create the key on your own machine.
How to use it
- Enter '2048' (or 3072, 4096) for size guidance, 'help' for the full local recipes, or paste a key to inspect.
- Press Process.
- Read the Format and Findings block. Public keys are what you should paste; the page flags private key material loudly if you paste it anyway.
Worked example
2048becomesRequested RSA size: 2048 bits
Equivalent symmetric security: ~112-bit
⚠ 2048-bit is the current minimum. Acceptable for TLS today, but plan a migration to 3072+ or Ed25519.
Generate it (run locally — never in a web page):
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -aes256 -out private.pem && chmod 600 private.pem
openssl rsa -pubout -in private.pem -out public.pem
Or with Node (add your own passphrase from an env var):
node -e "const c=require('crypto');const {privateKey,publicKey}=c.generateKeyPairSync('rsa',{modulusLength:2048,publicKeyEncoding:{type:'spki',format:'pem'},privateKeyEncoding:{type:'pkcs8',format:'pem',cipher:'aes-256-cbc',passphrase:process.env.PASS}});require('fs').writeFileSync('private.pem',privateKey,{mode:0o600})"
Safer alternative for almost every use case: Ed25519.
openssl genpkey -algorithm ED25519 -out ed25519.pem
Smaller keys, faster operations, no parameter choices to get wrong.
Storage rules:
• private.pem must be chmod 600 and never committed — add *.pem to .gitignore.
• Prefer a KMS/HSM or your platform secret store over a file on disk.
• Rotate on any suspected exposure. A leaked private key cannot be "revoked" from past traffic.Nothing is generated - the output is advice plus the commands you would run locally, and the warning tells you 2048 is the floor rather than a target.
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEx user@hostbecomesFormat: OpenSSH public key
Type: ssh-ed25519
Comment: user@host
Key family: ed25519
Verify the fingerprint (SHA-256 of the blob, the modern default):
ssh-keygen -lf <(echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEx …")
ssh-keygen -lvf id_ed25519.pub # -v also prints the randomart box
Findings:
• ed25519 — the recommended choice: fast, small, no parameter pitfalls.
Rules that prevent key incidents:
1. Private keys never leave the machine that uses them. Not in chat, not in a pastebin, not in a "validator".
2. Public keys are safe to share — that is their purpose.
3. Encrypt private keys at rest (PKCS#8 + AES-256, or a KMS).
4. Ed25519 over RSA for anything new: fewer parameters, no weak-size trap, faster.
5. Plan for rotation from day one — a key you cannot replace is a key you cannot protect.
This tool performed no network requests and stored nothing. All analysis is string/format inspection only — it cannot and does not recover private key material.A sample key line: the analysis is string based, so the type prefix and the comment are read literally and no key material is ever decoded.
When to use it
- Choosing between RSA 2048, 3072, 4096 and Ed25519 for a new service and wanting the exact commands rather than a blog post.
- Checking a public key's format before adding it to an authorized_keys file or a JWT verification configuration.
- Reviewing a JWK a colleague pasted into a ticket, to see whether an alg is set and whether private components leaked into it.
What it does not do
- The name overpromises. No key material is produced anywhere in the page, and the help text explains why: a synchronous page script cannot safely reach the CSPRNG, and a private key sitting in page memory is one compromised dependency away from leaking.
- PEM analysis is arithmetic on characters. It reports the base64 length and roughly three quarters of it as DER bytes, but never decodes the key, extracts a modulus or confirms the encoding is a valid key.
- The JWK modulus figure is approximate by construction - base64url length times 6/8, rounded up to a multiple of 8 - which is why a genuine 2048-bit modulus prints as '~2056 (plausible RSA modulus)'.
- A truncated JWK is rejected with 'That looks like a JWK but is not valid JSON.' because the branch requires JSON.parse to succeed, while a PEM with an unfamiliar header still analyses and prints 'Unrecognised PEM label.'.
- Pasting a private key into any browser page is a bad trade, this one included. The findings say so, and the correct follow-up is to rotate that key rather than keep using it.