To encrypt a file for someone with PGP you need one thing from them: their public key. The file you send can be opened only with the matching private key, which never leaves their machine. Most of the care goes into one step people skip: checking that the public key you were given really is theirs.
If you can run a command, use GnuPG. It is the reference implementation, the person you are writing to almost certainly decrypts with it or something tested against it, and it handles files of any size without holding them in memory.
gpg --import bob-public.asc
gpg --fingerprint [email protected]
gpg --encrypt --recipient EEE483729AF1D8583F4DB5D35399F36C41D31D57 \
--output report.pdf.gpg report.pdf
Import the key, compare its fingerprint with the owner, then encrypt to that fingerprint. The next sections go through each line.
This guide continues How to generate a PGP key pair. You don't need a key of your own to encrypt for someone else, but you will want one to sign and to keep a readable copy.
Import their key
The public key usually arrives as a .asc file or a block of text starting
-----BEGIN PGP PUBLIC KEY BLOCK-----. Import it:
gpg --import bob-public.asc
gpg: key 5399F36C41D31D57: public key "Bob Example <[email protected]>" imported
gpg: Total number processed: 1
gpg: imported: 1
Check the fingerprint before you use it
gpg --fingerprint [email protected]
pub ed25519 2026-10-18 [SC] [expires: 2028-10-17]
EEE4 8372 9AF1 D858 3F4D B5D3 5399 F36C 41D3 1D57
uid [ unknown] Bob Example <[email protected]>
sub cv25519 2026-10-18 [E]
Anyone can make a key that says "Bob Example [email protected]". The name and address are only text. If someone swapped the key on its way to you (in a forged email, on a keyserver, in a shared folder), you would encrypt the file to them, and the encryption would work perfectly. So read the fingerprint, the ten groups of four, back to Bob somewhere you already trust: in person, on a phone call, or on his own website. If it matches, the key is his.
Two things in that listing matter for encrypting. [ unknown] means you haven't
vouched for the key yet. The sub ... [E] line is the part that receives
encrypted files. A key with no [E] line can't be encrypted to at all.
Once the fingerprint matches, record that you checked it, with your own key:
gpg --quick-lsign-key EEE483729AF1D8583F4DB5D35399F36C41D31D57
It is a local signature: it stays in your keyring and is never published. Skip it and gpg stops on every encryption to that key until you answer:
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
Encrypt the file
gpg --encrypt --recipient EEE483729AF1D8583F4DB5D35399F36C41D31D57 \
--output report.pdf.gpg report.pdf
Apart from an occasional trustdb check, it prints nothing when it works. Naming the recipient by fingerprint, not by email address, means that a second key for the same address in your keyring can't be picked by mistake.
Keep the original extension and add .gpg. When Bob decrypts
report.pdf.gpg without --output, gpg writes report.pdf. Sent as
report.gpg, the same file comes back as report, with no extension.
.gpg or .asc
Add --armor and you get text instead of binary:
gpg --armor --encrypt --recipient EEE483729AF1D8583F4DB5D35399F36C41D31D57 \
--output report.pdf.asc report.pdf
The same 37,330-byte PDF, both ways:
| Output | Size | Starts with | Use it for |
|---|---|---|---|
report.pdf.gpg (binary) |
37,492 bytes | binary packets | an email attachment, a shared folder, a file transfer |
report.pdf.asc (--armor) |
50,835 bytes | -----BEGIN PGP MESSAGE----- |
pasting into a message, a ticket or a chat that only takes text |
Encryption adds about 160 bytes. Armor adds about a third. Both open with the same command, so the choice is only about how the file travels.
Encrypt to yourself as well
A file encrypted to Bob opens with Bob's private key, and with nothing else. That includes yours. To keep a copy you can read, name yourself as a second recipient:
gpg --encrypt \
--recipient EEE483729AF1D8583F4DB5D35399F36C41D31D57 \
--recipient 48B3254338A72766F95977779AC394E20BE087E1 \
--output report.pdf.gpg report.pdf
The file is encrypted once, and the key that unlocks it is wrapped once per
recipient, so the second recipient added 96 bytes, not a second copy of the
PDF. To do this every time, put encrypt-to followed by your fingerprint in
~/.gnupg/gpg.conf, or pass --encrypt-to with your fingerprint on the command
line.
What anyone can see in the file
Encryption hides the contents, not the envelope. With an empty keyring, holding
no key at all, gpg --list-packets shows who the file is for:
gpg --list-packets report.pdf.gpg
gpg: encrypted with ECDH key, ID 3CECA1B828EE08A4
gpg: encrypted with ECDH key, ID 1D7E134F083BB7C9
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 1D7E134F083BB7C9
data: [263 bits]
data: [392 bits]
# off=96 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 3CECA1B828EE08A4
data: [263 bits]
data: [392 bits]
# off=192 ctb=d2 tag=18 hlen=6 plen=37390 new-ctb
:encrypted data packet:
length: 37390
mdc_method: 2
Those are the IDs of the encryption subkeys (the sub lines in
gpg --list-keys --keyid-format=long). Anyone who has Bob's public key can tell
the file is for Bob, and the length gives away roughly how big the original
was. The original file name, report.pdf, is inside the encrypted part, so the
name you give the outer file is the only one a stranger sees.
Each recipient can see the key IDs of everyone else the file was encrypted to. If two recipients must not learn about each other, encrypt the file twice.
Prove it opens
On Bob's side, this is the whole job:
gpg --output report.pdf --decrypt report.pdf.gpg
gpg: encrypted with cv25519 key, ID 1D7E134F083BB7C9, created 2026-10-18
"Bob Example <[email protected]>"
When it matters, test before you send. Encrypt to yourself as well, decrypt your copy, and compare it with the original:
gpg --output check.pdf --decrypt report.pdf.gpg
cmp report.pdf check.pdf && echo identical
cmp prints nothing when the files match, so identical is the answer you
want. We ran this for the binary and the armored file, and for a file made by
the browser tool's encryption code: all three decrypted with GnuPG 2.4.7 to the
original bytes.
When gpg says Unusable public key
gpg: report.pdf: encryption failed: Unusable public key
There are three usual causes, in order of likelihood:
- The key can't receive encrypted mail. Its listing has no
[E]line. This happens withgpg --quick-generate-key "…" ed25519 default 2y, which makes a sign-only key. The owner fixes it withgpg --quick-add-key <their fingerprint> cv25519 encr 2yand sends you the key again. - The key has expired. The owner extends it and sends it again.
- You ran gpg without a terminal (a script,
--batch) and never marked the key as checked. Rungpg --quick-lsign-keyas above.
In the browser
The same three steps work in a tab, with nothing uploaded: keep their key, check its fingerprint, encrypt. The key is kept in this browser's own database, on this device, and only when you ask.
- Open PGP Import Keys and drop the
.asc, or paste the key under Key block. - Turn on Keep this key in this browser, then press Read this key.
- Read the user ID, the full fingerprint, the algorithm and the dates, and compare the fingerprint with the one the owner gave you. Stop here if it doesn't match.
- Press Import this key. The key now reads Already in your keyring.
Read the fingerprint here, before the key goes anywhere near a file.
- Open PGP Encrypt File and drop the file.
- Under Encrypt to, choose their key. If you keep a key pair of your own in this browser, choose it as well, for a copy you can open.
- Press Encrypt file. Under Readable by, check that the name and
fingerprint are the ones you meant, then save the result.
report.pdfcomes out asreport.pdf.gpg, the name gpg would give it.
A PDF encrypted to a public key you were sent, with the recipient read back out of the result.
PGP Encrypt File has no box to paste a key into: it encrypts only to keys kept in this browser, so import the key first. In a private window, or with site data blocked for this site, keys can't be kept, and the encrypt page has nothing to encrypt to.
When someone encrypts a file to a key pair you keep in this browser, made with PGP Generate Keys or imported with its private half, the browser opens it:
With a window instead of a terminal
Both of these are front ends to GnuPG, so everything above about fingerprints still applies. We haven't tested their menus, so check against their own instructions.
- macOS, GPG Suite: in Finder, right-click the file and choose Services, then OpenPGP: Encrypt File, and pick the recipients. See GPGTools' How to encrypt and sign text or files with GPG Services.
- Windows, Gpg4win: in Kleopatra, choose Sign/Encrypt, pick the file, and type the recipient under Encrypt for others. See the Gpg4win tutorial Encrypt a file, which notes that newer versions may differ.
A password instead of a key
gpg -c (--symmetric) is a different job. It encrypts with a password and no
keys at all:
gpg -c --output notes.pdf.gpg notes.pdf
Use it when the person has no PGP key and you can give them the password some other way, such as a phone call. Anyone who learns the password can open the file, and there is no per-person access to take away later. If they have a key, encrypt to the key.
Send it
Attach report.pdf.gpg to the email, or put it in the shared folder, the same
as any file. The file is safe to send over any channel, and the subject line and
body of your email are not encrypted, so keep the details for the file. If the
recipient writes back saying it won't open, the most likely reason is that
their copy of the private key isn't the one the fingerprint belongs to: run
gpg --list-packets on the file and compare the key ID with their sub line.
