Key Pair Generator
Generate cryptographically-secure Ed25519, ECDSA, and RSA key pairs entirely in your browser. Export real OpenSSH private keys (openssh-key-v1), PKCS#8/SPKI PEM with optional PBES2 passphrase protection, or JWK for JWKS endpoints — complete with SHA256/MD5 fingerprints, OpenSSH randomart, and a sign-and-verify check that proves the two halves match. Keys are generated via the Web Crypto API, the same primitives browsers use for TLS, and never leave your device.
Start here — one-click presets
Each preset picks the algorithm, key size and output format for a common scenario and generates a fresh key pair immediately. Fine-tune below if you need something else.
Options
Trailing label on the public key line — purely for identification.
OpenSSH keys are written unencrypted. Add a passphrase on your own machine with ssh-keygen -p -f id_ed25519 — that uses bcrypt_pbkdf, which only the OpenSSH tooling implements. Switch to PEM above if you want an encrypted key straight from this page.
Security Notice: Keys are generated locally in your browser using the Web Crypto API. Your private key is never transmitted, logged or stored — it exists only in this tab until you copy, download or reload the page.
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 a common SSH host key type.
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 including the public component), signature verification is exceptionally fast, and the spec eliminates many of the implementation pitfalls of ECDSA (no per-signature nonce 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 | 1190+ bytes | 32 bytes | 64 bytes |
| Signature size | 256 bytes | ~70 bytes (DER) | 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 |
| JOSE algorithm | RS256 / PS256 | ES256 | EdDSA |
| Default for TLS 1.3 | Acceptable | Yes | Yes (Ed25519 certs) |
When to choose RSA: Legacy compatibility (older enterprise systems, FIPS-constrained deployments), and JWT signing where RS256 is the established default for your stack.
When to choose ECDSA: Modern TLS certificates, cryptocurrency wallets (Bitcoin and Ethereum use secp256k1, a different curve, but the same algorithm family), and ES256/ES384 JWT signing.
When to choose Ed25519: New SSH configurations, new JWT signing infrastructure (EdDSA 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 (Ed25519, ECDSA, or RSA), the parameters (P-256/P-384/P-521 for ECDSA; 2048/3072/4096 bits plus PKCS#1 v1.5 or PSS for RSA), and the output format: OpenSSH for ~/.ssh, PKCS#8/SPKI PEM for OpenSSL and CA workflows, or JWK for JOSE and JWKS endpoints. Every generated key is accompanied by its SHA256 and MD5 fingerprints, OpenSSH randomart, and a live sign-and-verify check confirming the public and private halves are a genuine pair. 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. Blockchain developers working with Ed25519 chains such as Solana and Cardano (note that Bitcoin and Ethereum use secp256k1, a curve the Web Crypto API does not expose). 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
Open the page — an Ed25519 key pair in OpenSSH format is generated automatically, so a usable result is on screen before you touch anything.
Pick one of the presets at the top if it matches your goal: SSH key (Ed25519), JWT RS256 signing key, JWT ES256 signing key, self-signed TLS certificate, GitHub deploy key, or a long-term RS512 key. Each one regenerates immediately.
Need something else? Use the Options panel below the presets to set the algorithm (Ed25519, ECDSA P-256/P-384/P-521, or RSA 2048/3072/4096 with PKCS#1 v1.5 or PSS padding) and the output format.
For OpenSSH output, set the comment that will appear at the end of the public key line. For PEM output, optionally type a passphrase to encrypt the private key with PBES2 before it is displayed.
Click Generate Key Pair, then check the green 'public and private keys match' confirmation — the tool signs and verifies a test message before showing you anything.
Compare the SHA256 fingerprint and randomart shown next to the public key with what ssh-keygen -lv prints after you save the file; they must be identical.
Download the private key (id_ed25519, id_ecdsa, id_rsa, or private_key.pem) and the public key (.pub or public_key.pem). For SSH, move the private key to ~/.ssh and run chmod 600 on it.
Install the public key where it is needed: ~/.ssh/authorized_keys on the server, a JWKS endpoint for JWT verification, or a CSR sent to your CA for TLS.
For OpenSSH keys, add a passphrase locally with ssh-keygen -p -f ~/.ssh/id_ed25519 — OpenSSH uses bcrypt_pbkdf, which browsers cannot produce.
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
OpenSSH (a real openssh-key-v1 private key plus the authorized_keys line, for every algorithm), PEM (PKCS#8 private / SPKI public, for OpenSSL, Nginx, Apache and CA workflows), or JWK (for JOSE, JWT libraries and JWKS endpoints).
Fingerprints and randomart
Every key shows its SHA256 and legacy MD5 fingerprint plus the OpenSSH drunken-bishop randomart, byte-for-byte identical to ssh-keygen -lv — so you can confirm the file you saved is the key you saw.
Passphrase-protected PEM
PKCS#8 exports can be encrypted in-browser with PBES2: PBKDF2-HMAC-SHA256 at 600,000 iterations and AES-256-CBC, emitted as a standard ENCRYPTED PRIVATE KEY envelope that OpenSSL, Java and Python read directly.
Pair verification
Before the keys are displayed, the tool signs a test message with the private key and verifies it with the public key. A green confirmation means the two halves genuinely belong together.
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 the clipboard with one click, or download them under the conventional file names for the algorithm and format — id_ed25519 / id_ecdsa / id_rsa and their .pub counterparts for OpenSSH, private_key.pem and public_key.pem for PEM.
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.
Confirming a key file survived the trip intact
Scenario: You generated a key, downloaded it, moved it to a server, and want proof that the file on disk is the key you actually created.
✓ Compare the SHA256 fingerprint and randomart shown here with the output of ssh-keygen -lv -f ~/.ssh/id_ed25519.pub on the server. Identical art and fingerprint means the bytes match. ssh-keygen -y -f ~/.ssh/id_ed25519 re-derives the public key from the private key and must print the same line shown on this page.
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.
Private keys are exported as PKCS#8 PrivateKeyInfo and public keys as X.509 SubjectPublicKeyInfo; Ed25519 follows RFC 8410, ECDSA follows SEC 1, RSA follows RFC 8017. The OpenSSH encoder implements PROTOCOL.key exactly, and its output is verified against ssh-keygen -y, ssh-keygen -l and ssh-keygen -lv for Ed25519, ECDSA P-256/P-384/P-521 and RSA.
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 SSH key pair without ssh-keygen?
Click the 'SSH key (Ed25519)' preset — the page already generates one on load, so you usually just copy. The private key is a genuine openssh-key-v1 file (magic header, ciphername 'none', check-ints, public blob, private fields, comment, padding), not a relabelled PKCS#8 blob, so ssh-keygen and OpenSSH read it directly. Download it as id_ed25519, move it to ~/.ssh, run chmod 600 on it, and append the .pub line to ~/.ssh/authorized_keys on the server. Confirm the round trip with ssh-keygen -y -f ~/.ssh/id_ed25519, which must print exactly the public key line shown here.
What's the difference between RSA, ECDSA, and Ed25519?
RSA rests on the difficulty of factoring large semiprimes; usable keys are 2048-4096 bits and both keys and signatures are large. ECDSA uses the elliptic-curve discrete logarithm problem, so a 256-bit P-256 key gives roughly the security of a 3072-bit RSA key with far smaller keys and faster signing. Ed25519 (RFC 8032) is a 2011 EdDSA instantiation on Curve25519: 32-byte public keys, 64-byte signatures, deterministic nonces, and no branch-on-secret code paths, which removes the class of bugs that has repeatedly broken ECDSA implementations. All three are secure against classical computers and all three fall to a large quantum computer.
Is it safe to generate private keys in a browser?
This tool runs entirely in your browser via crypto.subtle — the same Web Crypto implementation the browser uses for TLS, backed by the operating system's CSPRNG, not JavaScript's Math.random. Your key never reaches a server, never gets logged, and no HTTP request carries it. Verify that yourself in DevTools' Network tab: generating a key produces zero requests. The keys are byte-for-byte equivalent to what ssh-keygen or openssl would produce for the same parameters. The one threat this cannot address is a compromised browser or a malicious extension with page access — for a key protecting high-value production infrastructure, generate it on a trusted, offline machine instead.
Should I use RS256, ES256, or EdDSA for JWT signing?
EdDSA (Ed25519) is the best default for new services: the smallest keys, the fastest verification, and no parameter choices to get wrong. ES256 (ECDSA P-256 + SHA-256) is the pragmatic middle ground — every mainstream JOSE library has supported it for years, and it is what most OIDC providers publish. RS256 is still the most widely accepted algorithm and the right pick when a partner's verifier is old or unknown; prefer PS256 (RSA-PSS) over RS256 if both sides support it, since PSS has a security proof that PKCS#1 v1.5 lacks. This tool labels each generated key with its JOSE algorithm so you can match it to your library's expectations.
Can I put a passphrase on the private key?
Yes, for PEM output. Type a passphrase before generating and the PKCS#8 key is wrapped in a standard EncryptedPrivateKeyInfo using PBES2: PBKDF2-HMAC-SHA256 with a 16-byte random salt and 600,000 iterations (current OWASP guidance) deriving a 256-bit key for AES-256-CBC. The result begins with -----BEGIN ENCRYPTED PRIVATE KEY----- and opens with openssl pkey, Java's EncryptedPrivateKeyInfo, Go, and Python's cryptography. OpenSSH output is deliberately unencrypted: OpenSSH protects its own keys with bcrypt_pbkdf, which the Web Crypto API cannot compute. Add one locally in a second with ssh-keygen -p -f ~/.ssh/id_ed25519.
How do I check that the key I downloaded is the key I saw?
Every generated key displays its SHA256 fingerprint (base64, unpadded, over the SSH public key blob), the legacy MD5 colon-hex fingerprint, and the OpenSSH 'drunken bishop' randomart on a 17x9 grid. These are computed with the same algorithms ssh-keygen uses, so after saving the file, ssh-keygen -lv -f ~/.ssh/id_ed25519.pub prints an identical fingerprint and an identical picture. The randomart exists precisely because people compare images reliably and base64 strings unreliably. The tool also signs and verifies a test message before display, so a key pair is never shown unless the two halves actually match.
What's the difference between the OpenSSH, PEM, and JWK outputs?
They are three encodings of the same key material, not three different keys. OpenSSH gives you the openssh-key-v1 private key file plus the single-line 'ssh-ed25519 AAAA... comment' format that ~/.ssh/authorized_keys expects. PEM gives you PKCS#8 PrivateKeyInfo and X.509 SubjectPublicKeyInfo base64 between BEGIN/END markers — the input format OpenSSL, Nginx, Apache, and most CAs expect. JWK gives you the RFC 7517 JSON object (kty OKP/EC/RSA) that JOSE libraries and JWKS endpoints consume. Convert between them later with ssh-keygen -y, openssl pkey, or the jose library; nothing is lost.
What key size should I pick, and how long does generation take?
Ed25519 and ECDSA P-256 generate in single-digit milliseconds and are the right default. RSA is the slow case: 2048-bit typically takes 100-500ms, 3072-bit around a second, and 4096-bit can take several seconds because the browser has to find two large random primes — an inherently variable search, so an occasional slow run is normal, not a hang. Use 2048-bit as the modern floor, 3072-bit for keys you expect to keep past 2030, and 4096-bit only when a compliance rule names it. If you are here for password storage rather than signing, you want a password hash instead — see our Argon2, bcrypt, and PBKDF2 tools.
Technical Specifications
Supported Formats
- ✓Ed25519: fixed 256-bit keys (RFC 8032 / RFC 8410)
- ✓ECDSA: P-256, P-384, P-521 curves (FIPS 186-4 / SEC 1)
- ✓RSA: 2048, 3072, 4096-bit keys, PKCS#1 v1.5 or PSS padding, SHA-256/384/512 (RFC 8017)
- ✓Output: OpenSSH (openssh-key-v1 private key + authorized_keys line), PEM (PKCS#8 private / SPKI public), JWK (RFC 7517)
- ✓Passphrase protection for PEM: PBES2 (RFC 8018) — PBKDF2-HMAC-SHA256, 600,000 iterations, 16-byte salt, AES-256-CBC
- ✓Fingerprints: SHA256 (base64, unpadded) and MD5 (colon hex) over the SSH public key blob, plus OpenSSH 17x9 randomart
- ✓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: Ed25519 and ECDSA are near-instant; RSA takes 100ms to several seconds, rising sharply at 4096 bits
- •Browsers: All modern browsers. Ed25519 needs Chrome/Edge 137+, Firefox 129+, or Safari 17+; the tool feature-tests it and falls back to ECDSA P-256 automatically
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 single-line public key is what goes into authorized_keys; the openssh-key-v1 private key goes into ~/.ssh/ with mode 600. Download names follow the algorithm: id_ed25519, id_ecdsa, id_rsa.
- Encrypt PEM private keys with a passphrase here (PBES2 / PBKDF2-HMAC-SHA256 600,000 iterations / AES-256-CBC). For OpenSSH keys, add the passphrase locally with ssh-keygen -p -f id_ed25519 — OpenSSH's bcrypt_pbkdf KDF is not available to browsers.
- Always compare the SHA256 fingerprint or randomart shown here against ssh-keygen -lv on the machine where you installed the key. It catches truncated downloads and copy-paste damage instantly.
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.