Key Pair Generator
Generate cryptographically-secure RSA, ECDSA, and Ed25519 public/private key pairs entirely in your browser. Output in PEM, JWK, or SSH format for use with OpenSSL, JWT signing, SSH ~/.ssh/authorized_keys, TLS certificates, cryptocurrency wallets, and any asymmetric-crypto use case. Keys are generated via the Web Crypto API — the same primitives browsers use for TLS — and never leave your device.
Security Notice: Keys are generated locally in your browser using the Web Crypto API. Your private keys never leave your device. Always keep your private keys secure and never share them.
Popular Use Cases
One-click presets that pick the right algorithm, key size, and format for common scenarios.
How key pair cryptography works
A key pair is a mathematically-linked pair of values: the public key (which you publish, share, send via insecure channels) and the private key (which you guard absolutely). Whatever asymmetric algorithm you choose, the same fundamental property holds: data encrypted with the public key can only be decrypted with the matching private key, and signatures created with the private key can be verified by anyone holding the public key.
The mathematics differs across algorithms, but the use cases overlap. RSA uses the difficulty of factoring large numbers — it's the oldest mainstream asymmetric algorithm (designed by Rivest, Shamir, and Adleman in 1977), has the broadest library support, and remains the right choice when you need maximum compatibility with legacy systems. Key sizes are big: 2048 bits is the modern minimum, 3072 bits and 4096 bits are common for higher-security applications.
ECDSA (Elliptic Curve Digital Signature Algorithm) uses the discrete logarithm problem over elliptic curves. The math is more recent, the keys are dramatically smaller for equivalent security (a 256-bit ECDSA key matches a 3072-bit RSA key in cryptographic strength), and signature operations are significantly faster. ECDSA is the default for modern TLS deployments, Bitcoin and Ethereum, and most current SSH configurations.
Ed25519 is the newest of the three — a variant of EdDSA designed for speed, simplicity, and resistance to implementation mistakes. Ed25519 keys are tiny (32 bytes for the public key, 64 bytes for the private key combined with the public component), signature verification is exceptionally fast, and the spec eliminates many of the implementation pitfalls of ECDSA (no nonces to get wrong, deterministic signatures by default). For new SSH configurations, JWT signing keys, and any greenfield asymmetric crypto, Ed25519 is the right starting choice.
For each algorithm, the public and private keys are mathematically related but the private key cannot feasibly be derived from the public key — that's the entire foundation of public-key cryptography. The asymmetry only exists because certain mathematical operations are easy to do forward (multiplying primes together, point multiplication on a curve) and computationally infeasible to reverse without the secret.
Algorithm Comparison: RSA vs ECDSA vs Ed25519
| Property | RSA-2048 | ECDSA P-256 | Ed25519 |
|---|---|---|---|
| Public key size | 256 bytes | 64 bytes | 32 bytes |
| Private key size | 1216 bytes | 32 bytes | 64 bytes |
| Signature size | 256 bytes | ~70 bytes | 64 bytes |
| Sign performance | Slow | Fast | Fastest |
| Verify performance | Fastest | Slow | Fast |
| Library support | Universal | Universal | Modern (2018+) |
| Quantum-vulnerable | Yes | Yes | Yes |
| Default for new SSH | No | No | Yes |
| Default for JWT signing | RS256 still common | ES256 modern | EdDSA emerging |
| Default for TLS 1.3 | Acceptable | Yes | Yes |
When to choose RSA: Legacy compatibility (old enterprise systems, FIPS 140-2 strict deployments where RSA is mandated), JWT signing where RS256 is the established default for your stack.
When to choose ECDSA: Modern TLS certificates, cryptocurrency wallets (Bitcoin, Ethereum), most current JWT signing scenarios (ES256/ES384).
When to choose Ed25519: New SSH configurations, new JWT signing infrastructure (EdDSA algorithm in JOSE), any greenfield application where you want the simplest and fastest defaults.
Learn more
For practitioner-focused coverage of password hashing, JWT signing key choices, and the broader cryptographic stack, read our Password Hashing 2026 Guide.
About Key Pair Generator
Public-key (asymmetric) cryptography is the backbone of modern secure communication. Unlike symmetric encryption (one shared secret), asymmetric cryptography uses a mathematically-linked pair of keys: a public key that you share freely, and a private key that you keep secret. Anyone can encrypt with the public key, but only the private key can decrypt. Anyone can verify a signature made with the private key by checking against the public key. The Key Pair Generator creates cryptographically-secure key pairs entirely in your browser using the Web Crypto API — the same primitives that browsers use for TLS handshakes and JWT verification. You choose the algorithm (RSA, ECDSA, or Ed25519), the key size (2048/3072/4096 for RSA or curve selection for ECDSA), and the output format (PEM for OpenSSL/SSH, JWK for JOSE/JWT applications, or raw SSH-format for ~/.ssh/authorized_keys deployment). Your private key is generated locally, displayed locally, and never transmitted to any server.
Why use a Key Pair Generator?
Manually generating key pairs requires installing OpenSSL, remembering the correct command-line incantation (`openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048` vs the equivalent for EC), and ensuring your environment's randomness source is actually random. The browser-based Web Crypto API removes all of those concerns: it's standardized across modern browsers, uses the operating system's cryptographic RNG (which is significantly better than userspace JavaScript randomness), and produces keys that are bit-for-bit identical to what OpenSSL would generate. The bigger payoff is convenience for ad-hoc use cases. Generating a throwaway SSH key for a one-time deployment, an Ed25519 signing key for a local JWT test, or a PEM-format RSA key for a CI/CD secret — these are moments when you don't want to context-switch to a terminal and look up the right OpenSSL flags. Click, copy, paste, done. The keys are production-quality (the algorithms are the same ones standardized in RFC 8017 for RSA, FIPS 186-4 for ECDSA, and RFC 8032 for Ed25519), so the output is just as usable for production as for testing.
Who is it for?
Backend engineers configuring JWT signing keys for new authentication services. DevOps engineers generating SSH key pairs for CI/CD pipelines, Kubernetes deployments, and bastion-host access. Cryptocurrency and blockchain developers creating ECDSA or Ed25519 wallet keys. Security researchers testing TLS/SSL configurations with self-signed certificates. Mobile and IoT developers embedding asymmetric keys for device attestation. CTF participants generating keys for cryptography challenges. Anyone implementing the SSH ~/.ssh/authorized_keys flow, GitHub deploy keys, GPG-style signing workflows, or signed JWT authentication. Students learning the difference between symmetric and asymmetric cryptography by generating their first key pair and inspecting the structure.
How to use the tool
Choose your algorithm: Ed25519 for modern SSH and JWT (recommended for new setups), RSA-2048 for broad legacy compatibility, ECDSA P-256 for TLS and cryptocurrency.
Select key size for RSA (2048-bit minimum for new deployments, 3072 or 4096 for long-lived keys) or curve for ECDSA (P-256 is the most widely supported).
Choose output format: PEM for OpenSSL and most CA workflows, JWK for JWT signing keys and JOSE applications, SSH for direct deployment to ~/.ssh/authorized_keys.
Click Generate Key Pair — generation happens entirely in your browser via the Web Crypto API. Keys appear in 200-2000ms depending on algorithm and key size.
Copy or download the private key. For SSH, save as ~/.ssh/id_ed25519 (or id_rsa) and chmod 600. For JWT, store in a secrets manager. For TLS, use OpenSSL to create a CSR.
Copy the public key. For SSH, add to the remote server's ~/.ssh/authorized_keys. For JWT, publish via a JWKS endpoint. For TLS, send to the CA with your CSR.
Verify the key pair works before relying on it: SSH with the private key to your server, sign a test JWT and verify with the public key, or test TLS by establishing a connection with the certificate.
Key Features
Three modern algorithms
RSA (2048/3072/4096-bit), ECDSA (P-256/P-384/P-521 curves), and Ed25519. Pick the right algorithm for your use case without leaving the page.
Three output formats
PEM (for OpenSSL, Nginx, Apache, most CA workflows), JWK (for JOSE/JWT applications, OIDC providers), or SSH format (drop directly into ~/.ssh/authorized_keys).
Client-side generation
Keys are generated locally in your browser using the Web Crypto API. The private key never leaves your device — there's no server-side generation, no telemetry, no logging.
Cryptographic RNG
Uses the browser's underlying OS cryptographic random number generator (via crypto.getRandomValues), which is significantly stronger than userspace JavaScript randomness. The same RNG used for TLS in modern browsers.
Copy and download
Copy keys to clipboard with one click, or download as named files (private_key.pem, public_key.pem) for direct use in your deployment.
Standards-compliant output
RSA keys conform to PKCS #8 (private) and SPKI (public). ECDSA keys follow SEC 1. Ed25519 keys follow RFC 8410. Every output is bit-for-bit compatible with OpenSSL and other industry tooling.
Common Use Cases
Generating an SSH key pair
Scenario: You're setting up SSH access to a new server and need to generate a key pair without dropping to a terminal or installing ssh-keygen.
✓ Choose Ed25519 (the modern SSH default), select SSH output format. Copy the public key into your server's ~/.ssh/authorized_keys file, save the private key as ~/.ssh/id_ed25519 with chmod 600. Same result as ssh-keygen -t ed25519, no installation needed.
Creating a JWT signing key pair
Scenario: You're configuring JWT authentication for a new web service. You need an RSA or ECDSA key pair where the private key signs tokens and the public key validates them.
✓ For broad library support, choose RSA-2048 in PEM format — this is the RS256 default in JWT terminology. For modern setups, choose Ed25519 in JWK format (the EdDSA algorithm in JOSE). Sign tokens server-side with the private key, distribute the public key as a JWKS endpoint for client-side verification.
Self-signed TLS certificate for local development
Scenario: You need a TLS certificate for local development (localhost HTTPS) without going through a real CA.
✓ Generate an ECDSA P-256 key pair in PEM format. Combine it with OpenSSL's certificate signing flow (openssl req -new -key private_key.pem -out csr.pem) to produce a self-signed certificate that browsers can be configured to trust for development.
Cryptocurrency wallet keys
Scenario: You're building or testing a cryptocurrency wallet that uses ECDSA (Bitcoin, Ethereum) or Ed25519 (Solana, Cardano) for address derivation.
✓ Generate an ECDSA P-256 key (or Ed25519 for newer chains). Derive the wallet address from the public key using the chain's specific encoding rules. The private key is the seed — guard it with the same paranoia you'd give a real wallet.
GitHub deploy key
Scenario: You're setting up automated deployment from CI/CD to a GitHub repository and need a deploy key for that specific repo.
✓ Generate an Ed25519 key pair in SSH format. Add the public key to your GitHub repo's Deploy Keys settings, store the private key as a CI/CD secret. The private key authenticates the deployment without granting account-wide access.
RSA keys are generated per PKCS #8 and SPKI standards. ECDSA keys follow SEC 1. Ed25519 keys conform to RFC 8410. Output is bit-for-bit compatible with OpenSSL and ssh-keygen.
All key generation happens in your browser using the Web Crypto API. Private keys are never transmitted to any server, never logged, never stored. No cookies, no analytics tracking your inputs.
Static front-end; no server-side dependency for key generation. Globally distributed CDN delivery.
Frequently Asked Questions
How do I generate an RSA key pair online safely?
Safe online RSA key generation requires that the key never touches a server. This tool uses the browser's built-in Web Crypto API (crypto.subtle.generateKey), the same primitive that browsers use internally for TLS handshakes. The private key is generated in browser memory, displayed in your browser, and never transmitted anywhere — there's no HTTP request that includes the private key, no analytics, no logging. The same Web Crypto API is used by major password managers and authenticator apps for in-browser key operations. If you need maximum paranoia, run the generation on an air-gapped machine — but for normal development use, browser-based generation via Web Crypto is cryptographically equivalent to running ssh-keygen or openssl locally.
What's the difference between RSA, ECDSA, and Ed25519?
RSA is the oldest and most widely-supported, using the difficulty of factoring large numbers; modern keys are 2048-4096 bits. ECDSA uses elliptic curves and produces dramatically smaller keys for equivalent security — a 256-bit ECDSA key matches a 3072-bit RSA key. ECDSA is the modern TLS and JWT default. Ed25519 is newer (2011), even faster than ECDSA, and resistant to common implementation mistakes — it's the right default for new SSH configurations and modern JWT signing. All three remain secure against classical computers; all three are vulnerable to future quantum computers (which is why post-quantum algorithms like ML-KEM are being standardized for 2026+ deployments).
What key size should I use for RSA?
2048-bit is the modern minimum and acceptable for most use cases through 2030. 3072-bit is the right choice for long-lived keys (5+ year deployments) where you want margin against incremental cryptanalytic improvements. 4096-bit gives you no meaningful additional security against classical attacks compared to 3072-bit, but adds 30-50% latency to every signature verification — only use it when explicitly required (some compliance frameworks specify 4096-bit minimum). If your use case has any performance sensitivity, prefer ECDSA P-256 or Ed25519 over large RSA keys.
Is browser-based key generation as secure as openssl?
Yes, for the same reason that TLS in your browser is as secure as TLS via curl: both use the same underlying cryptographic primitives. The Web Crypto API (window.crypto.subtle) is a standardized browser API that calls into the operating system's cryptographic libraries — the exact same code that OpenSSL would use. The RNG is the OS cryptographic RNG (CSPRNG), not userspace JavaScript randomness. The output is bit-for-bit compatible with openssl's output for the same algorithm and parameters. The one place where browser generation could matter is if your browser itself is compromised — but if that's true, openssl on the same machine would also be compromised.
How do I use the generated key with OpenSSH or ssh-keygen?
For OpenSSH compatibility, choose Ed25519 (the modern SSH default) or RSA, with SSH output format. Save the private key as ~/.ssh/id_ed25519 (or ~/.ssh/id_rsa) and set permissions with chmod 600. Save the public key as the corresponding .pub file. To enable login to a remote server, copy the contents of the .pub file into the server's ~/.ssh/authorized_keys file. This is the same setup ssh-keygen would produce; the keys are interoperable with all OpenSSH versions and any SSH client.
What format should I use for JWT signing keys?
It depends on your JWT library. The JOSE specifications (RFC 7515-7518) define JWK (JSON Web Key) as the canonical format, with each algorithm having a specific JWK structure — kty='RSA' for RSA, kty='EC' for ECDSA, kty='OKP' with crv='Ed25519' for Ed25519. Most modern JWT libraries (jose, jsonwebtoken in Node, PyJWT, python-jose) accept either PEM or JWK input. For publishing your public key as a JWKS endpoint (which is the standard pattern for distributed JWT verification), use JWK format. For storing your private key as a secret in CI/CD or a secrets manager, PEM is more common.
How long should a key pair be valid for?
There's no absolute time limit — keys don't expire mathematically. But operationally, plan to rotate keys based on use case: TLS certificate keys, every 1-2 years (most CAs cap certificate validity at 825 days now); JWT signing keys, every 6-12 months with overlapping validity periods to avoid sudden cutoffs; SSH keys for personal use, every 1-2 years or whenever you change machines; service account keys, every 90 days minimum for high-value services. Use the rotation as an opportunity to revisit your algorithm choice — a key generated in 2026 might be RSA-2048 because the legacy system needed it, but the rotated key in 2027 could be Ed25519 once you've upgraded the legacy system.
Can I convert between PEM, JWK, and SSH formats?
Yes — the formats are different encodings of the same mathematical key. PEM-to-JWK: use the jose library (Node), python-jose (Python), or jose-jwt (any language). JWK-to-PEM: same libraries, reverse direction. PEM-to-SSH: use ssh-keygen -y -f keyfile.pem to extract the SSH-format public key from an OpenSSL-format private key. The underlying key material is identical across formats; you're just changing how it's serialized. This is why you can generate once in one format and convert later if your toolchain changes.
What happens if my private key leaks?
Treat it as fully compromised and rotate immediately. For SSH keys: remove the public key from all ~/.ssh/authorized_keys files where it was added, generate a new key pair, redeploy the new public key. For TLS certificate keys: revoke the corresponding certificate via your CA's revocation process, generate a new key pair, issue a new certificate. For JWT signing keys: rotate to a new key pair immediately, revoke all outstanding tokens (which is harder than it sounds — JWT's stateless design means tokens are valid until they expire or you maintain a blocklist). For cryptocurrency wallet keys: transfer all funds to a new wallet immediately; a leaked wallet private key has approximately the half-life of an ice cube on a hot day.
Do I need a passphrase on my private key?
For interactive use (SSH keys you type a passphrase for at login), yes — a passphrase adds defense-in-depth if the key file leaks. For automated use (CI/CD service accounts, server-to-server JWT signing), no — a passphrased key requires the passphrase at runtime, which would have to be stored somewhere alongside the key, defeating the purpose. The right model for automated services is: store the private key in a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager), access it via IAM-controlled API, never write it to disk in plain form. The secrets manager's access control is the protection, not a passphrase on the key file.
Technical Specifications
Supported Formats
- ✓RSA: 2048, 3072, 4096-bit keys (RFC 8017)
- ✓ECDSA: P-256, P-384, P-521 curves (FIPS 186-4 / SEC 1)
- ✓Ed25519: fixed 256-bit keys (RFC 8032 / RFC 8410)
- ✓Output: PEM (PKCS #8 private / SPKI public), JWK (RFC 7517), SSH (OpenSSH format)
- ✓All algorithms generated via Web Crypto API — same primitives browsers use for TLS
Limits & Performance
- •File Size: Two strings (private + public) per generation
- •Validations: Live in-browser generation
- •Response Time: 200-2000ms depending on algorithm and key size (4096-bit RSA is slowest)
- •Browsers: All modern browsers (Chrome 60+, Firefox 60+, Safari 11+, Edge 79+)
Pro Tips
- Ed25519 is the modern default for new SSH and JWT setups. Choose it over RSA unless you have a specific compatibility constraint.
- For RSA, 2048-bit is the floor. 3072-bit is the right choice for long-lived keys (5+ year deployments). 4096-bit produces noticeable performance overhead on every signature verification — only use it when explicitly mandated.
- JWK format includes a 'kid' (key ID) in production scenarios. The tool's JWK output is a minimal version — add your own kid field when publishing to a JWKS endpoint.
- Private keys should never be committed to git, even in test branches. Use .gitignore, secrets managers (Vault, AWS Secrets Manager, GitHub Secrets), or local-only files. Once a private key hits a public history, treat it as compromised.
- Don't reuse key pairs across services. Each service gets its own key pair so a compromise of one doesn't propagate. Generating new key pairs is cheap; rotating compromised infrastructure is expensive.
- PEM and JWK are convertible. A key pair generated as PEM can be converted to JWK with `jose` or `python-jose` libraries, and vice versa. The underlying mathematical key is the same — only the encoding differs.
- For SSH keys, the public key in SSH format is what goes into authorized_keys. The private key in OpenSSH format (or PEM, both work) goes into ~/.ssh/. Don't mix them up.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.