Generate an OpenPGP key pair in your browser. Curve25519, NIST curves or RSA up to 4096-bit, with passphrase and expiry. Key never leaves your device.
This PGP key generator creates a complete OpenPGP key pair — public key, private key, fingerprint and key IDs — entirely inside your browser. Enter a name and email, choose a key type and an expiration, set a passphrase, and the tool produces ASCII-armored keys you can download or copy. Key generation uses the OpenPGP.js library running as client-side JavaScript. The private key is created on your machine and never leaves it: there is no upload, no server-side generation, and no account.
That distinction matters more here than for almost any other tool on this site. A private key is the whole secret. Any web service that generates a key pair on its server has, by definition, seen your private key. This one cannot, because the cryptography happens in the page you already loaded — you can verify that by opening your browser’s network tab during generation, or by disconnecting from the network after the page loads and generating a key anyway.
Client-side generation removes the server from the trust equation, but it does not remove the other risks, and you should be clear-eyed about them:
gpg --full-generate-key on the server, or directly on a hardware token such as a YubiKey or a smartcard, so the private key never exists as a file at all. This tool is best suited to personal keys, learning, testing and one-off encryption tasks.Name (comment) <email>. Use the email address people will actually use to reach you; correspondents look keys up by it.| Key type | Approx. security level | Notes |
|---|---|---|
| ECC Curve25519 | ~128-bit | Recommended default. Fast generation, small keys, fast signatures, no NIST-curve concerns. Supported by GnuPG 2.1+ and every modern client. |
| ECC NIST P-256 | ~128-bit | Widely supported, including in FIPS-constrained environments. Choose when a compliance regime names NIST curves. |
| ECC NIST P-384 | ~192-bit | Higher margin; still broadly supported. |
| ECC NIST P-521 | ~256-bit | Highest NIST curve, but the least consistently supported. Verify your correspondents’ tooling first. |
| RSA 2048 | ~112-bit | The floor for RSA. Use only where something old cannot handle anything else. |
| RSA 3072 | ~128-bit | The RSA equivalent of Curve25519’s strength, at roughly 24 times the key size. |
| RSA 4096 | ~140-bit | Maximum practical RSA. Noticeably slower to generate; the extra margin over 3072 is modest. |
Unless you have a specific compatibility or compliance reason, pick Curve25519. The elliptic-curve keys are a fraction of the size of RSA at equivalent strength, generate in a moment rather than tens of seconds, and produce much smaller signatures — which is why they have become the default in modern OpenPGP tooling.
Every OpenPGP key has a 160-bit fingerprint, normally shown as 40 hexadecimal characters. The tool also shows a long key ID (the last 16 hex characters of the fingerprint) and a short key ID (the last 8). Only the full fingerprint should ever be used for verification. Short key IDs are just 32 bits and collisions have been generated deliberately — in 2016 a well-publicised exercise produced colliding short IDs for a large number of prominent keys on the public keyservers. If someone asks you to confirm a key, compare all 40 characters, ideally over a channel other than the one that delivered the key.
A worked example of the shape of these values:
Fingerprint: 3F5A 9C21 8E4B 7D06 1A93 C852 BB40 17FE 6D2C 90A1
Long key ID: BB4017FE6D2C90A1
Short key ID: 6D2C90A1Setting an expiration date is good practice, and the common objection — “I do not want to lose my identity in two years” — misunderstands how it works. An expiration date on an OpenPGP key can be extended at any time by the key holder, as long as you still have the private key and passphrase. Its real function is a dead-man’s switch: if you lose access to the key or simply stop using it, it eventually stops being presented to the world as a valid way to reach you. A key set to never expire and then lost stays on the keyservers forever, and people will keep encrypting mail you can no longer read.
Two years is a reasonable default. If you generate a key here that you intend to keep, also generate a revocation certificate in your local GnuPG installation once you import the key — that is what lets you retire the key if the passphrase is lost.
To import the key pair you just generated into GnuPG, save each block to a file and run:
gpg --import public-key.asc
gpg --import private-key.asc
gpg --list-secret-keys --keyid-format LONG
gpg --edit-key you@example.com trustThen encrypt and sign in the usual way:
gpg --encrypt --sign --armor -r recipient@example.com message.txt
gpg --decrypt message.txt.asc
gpg --detach-sign --armor release.tar.gzTo publish the public key so others can find it, export the armored public block and upload it to a keyserver or, better, publish it via Web Key Directory on your own domain so verification is tied to a domain you control.
For TLS rather than email — certificate signing requests, self-signed certificates and format conversion — use the certificate CSR generator, and inspect existing certificates with the X.509 certificate decoder. The secure password generator is a good way to produce the passphrase that protects this key, and the hash generator covers the checksum side of verifying downloads you have just validated a signature on.
The generation itself runs locally using OpenPGP.js and the browser’s cryptographic random number generator, and nothing is transmitted. The risk that remains is the machine you are using: generate only on a device you control and trust, set a strong passphrase, and move the private key straight into secure storage. For organisational or high-value keys, generate on the target system or on a hardware token instead.
PGP was the original 1991 program. OpenPGP is the open standard describing the message and key formats. GPG (GnuPG) is the widely used free implementation of that standard. Keys generated here follow the OpenPGP standard and therefore work with GnuPG and other compliant clients.
ECC Curve25519 unless you have a reason not to. Choose a NIST curve if a compliance regime requires it, or RSA 3072/4096 if you must interoperate with older software that predates elliptic-curve OpenPGP support.
No. The passphrase encrypts the private key and there is no backdoor, no reset and no recovery. If you lose it, the key is gone — which is precisely why you generate a revocation certificate while you still have access.
The public key is for distribution: people use it to encrypt messages to you and to verify your signatures. The private key stays with you and is used to decrypt and to sign. Share the public key freely; never share the private key.
RSA key generation must find two large random primes, which is a search process with no fixed running time. At 4096 bits that can take tens of seconds even on fast hardware. Elliptic-curve keys have no such step and generate almost instantly.
Yes. Import the key into GnuPG, then set git config user.signingkey <long key ID> and git config commit.gpgsign true. Add the public key to your Git host so signatures show as verified.
Clients stop treating it as valid for new encryption and warn on signature verification. Existing signatures made before expiry generally still verify. You can extend the expiration at any time with the private key, so expiry is recoverable in a way that a lost passphrase is not.
It makes you findable, but the older SKS-style keyservers cannot delete anything, so treat an upload as permanent and public — including the email address in the user ID. Modern options such as keys.openpgp.org require email confirmation and support removal, and Web Key Directory on your own domain gives you the most control.
No. Generation happens in your browser tab; the key exists in that page’s memory and in whatever you download. Close the tab and it is gone, so download it before you leave.
PGP (Pretty Good Privacy) key generation creates a mathematically linked pair of cryptographic keys—a public key and a private key—used for encrypting messages, signing files, and verifying identity. PGP has been a cornerstone of secure communication since Phil Zimmermann released it in 1991, and its open standard (OpenPGP, defined in RFC 4880) remains widely used for email encryption, software distribution verification, and secure file transfer.
The core principle is asymmetric cryptography: the public key encrypts data that only the corresponding private key can decrypt, and the private key creates signatures that anyone with the public key can verify. This eliminates the need to share secret keys through insecure channels—a fundamental problem in symmetric cryptography.
A PGP key pair consists of several components:
| Component | Purpose | Visibility |
|---|---|---|
| Public key | Encrypt messages to you; verify your signatures | Shared freely |
| Private key | Decrypt messages sent to you; create signatures | Never shared |
| User ID | Associates name and email with the key | Public |
| Subkeys | Separate keys for signing, encryption, authentication | Linked to primary |
| Key ID / Fingerprint | Unique identifier for the key (last 8/16 hex chars or full 40-char SHA-1) | Public |
| Expiration date | When the key automatically becomes invalid | Public |
Key algorithm options:
When generating a key, the generator creates random prime numbers (RSA) or curve points (ECC), derives the key pair, and packages everything into the OpenPGP format with your user ID and self-signature.
PGP (Pretty Good Privacy) is an encryption program that provides cryptographic privacy and authentication for data communication. It is used for signing, encrypting, and decrypting texts, emails, files, and more. PGP helps protect your sensitive communications from unauthorized access and ensures message authenticity.
Yes, all PGP keys are generated entirely in your browser using client-side JavaScript. Your private key never leaves your device and is not transmitted to any server. This tool uses the OpenPGP.js library, which implements the OpenPGP standard for secure key generation.
For new keys, we recommend ECC Curve25519 as it offers excellent security with better performance and smaller key sizes than RSA. ECC keys are modern and widely supported. RSA keys (2048, 3072, or 4096 bits) are still secure but are considered legacy and should only be used when compatibility with older systems is required.
Yes, setting a strong passphrase is highly recommended. A passphrase encrypts your private key file, so even if someone gains access to your private key file, they cannot use it without knowing the passphrase. Choose a long, memorable passphrase that is difficult to guess.
Setting an expiration date provides an additional security layer. If your key is ever compromised, the damage is limited to the expiration period. It also encourages good key hygiene by prompting you to rotate keys periodically. We recommend setting a 2-year expiration for most use cases.
Your public key can be shared freely with anyone who wants to send you encrypted messages or verify your digital signatures. Your private key must be kept secret and secure, as it is used to decrypt messages sent to you and create digital signatures. Never share your private key with anyone.