Generate Ed25519 or RSA SSH keypairs entirely in your browser. The private key never leaves this page. Output is OpenSSH format, ready for ~/.ssh/, GitHub, GitLab, AWS, or any host that takes authorized_keys.
-chmod 600 ~/.ssh/id_ed25519 (or whatever you named it)
$ ssh-keygen -y -f ~/.ssh/id_ed25519 (verifies the key parses cleanly)
$ ssh-add ~/.ssh/id_ed25519 (load into the agent)
Ed25519 is the right answer for almost every use case in 2026. The keys are short (a single line of text), generation is fast, signing and verification are fast, and the underlying curve (Curve25519) was designed to avoid the implementation footguns that plague older algorithms. GitHub, GitLab, AWS, and basically every modern SSH server accept Ed25519. Pick this one unless you have a documented reason not to.
RSA 3072 or 4096 is the right answer when you have to interoperate with legacy systems that pre-date Ed25519 support, or when a compliance regime explicitly mandates RSA. Generation is slower (you might wait a few seconds for 4096-bit keys), keys are much larger, and the security margin per byte is worse than Ed25519. RSA 2048 is included for old-system compatibility but should not be a new-key default in 2026.
SSH has a few historical key formats (PEM, PuTTY .ppk, OpenSSH legacy, OpenSSH v1). This generator outputs the modern OpenSSH v1 format, the same format ssh-keygen produces by default since OpenSSH 7.8. The private key starts with -----BEGIN OPENSSH PRIVATE KEY----- and the public key is the familiar single line: ssh-ed25519 AAAA... user@host.
This format is supported by every actively-maintained SSH client and server. PuTTY (Windows) needs you to convert to .ppk via PuTTYgen if that is your client.
Save the private key to ~/.ssh/id_ed25519 (or id_rsa for RSA). Save the public key to the same path with a .pub suffix. Then:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pubPermissions matter. The SSH client refuses to use a private key with permissions broader than 600.
To add the public key to a remote host's authorized_keys:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostFor GitHub or GitLab: settings, SSH keys, paste the contents of the .pub file (the single line starting with ssh-ed25519 or ssh-rsa).
The fastest sanity check that a generated private key is valid OpenSSH format is:
ssh-keygen -y -f ~/.ssh/id_ed25519This re-derives the public key from the private key. If it prints a public key matching the one this tool gave you, the file is valid. If it errors, the file is corrupted (in which case generate a fresh pair, do not try to repair).
Yes, for any key you actually use. This tool generates keys without a passphrase because passphrase-protected keys require a key-derivation function (bcrypt-pbkdf) that is non-trivial in the browser. After generation, encrypt the key with a passphrase using:
ssh-keygen -p -f ~/.ssh/id_ed25519It will prompt for a new passphrase and re-encrypt the file in place.
This tool uses the Web Crypto API (crypto.subtle.generateKey) for key generation, the same primitive your browser uses for TLS and WebAuthn. Keys are generated entirely in your browser. Nothing is transmitted, stored, logged, or persisted. Closing this tab destroys the key permanently. You can verify this by opening your browser's network tab while using the tool: zero requests fire when you click Generate.
That said, browser-generated keys live in browser memory at some point during generation. If you are generating a high-stakes production key (a deploy key for a critical system, a CA root, etc.), the gold standard is still ssh-keygen -t ed25519 on an air-gapped machine. For day-to-day developer keys, this tool is fine.
Need a strong passphrase to encrypt this key with? Try the Password Generator. Want to hash the public key for verification scripts? Hash Generator. Encoding key bytes for an API call? Base64 Encoder.