Most people meet PGP through email, but email is only one of the things the tool can protect. The same key pair that encrypts a message can encrypt a tax return sitting in your cloud storage folder, a password export before it goes onto a USB stick, or a database backup that leaves your machine. If you already have a key and know how encryption works, the file workflow is a short step, and it covers the situations where email encryption does nothing at all.
Why file encryption is a different problem
Encrypted email protects a message in transit. Once it arrives, the recipient decrypts it and the plaintext lives in their inbox, on their phone, and in whatever backup their mail provider keeps. That is usually acceptable for conversation. It is a poor fit for documents you want to stay encrypted at rest: contracts, medical records, scans of identity documents, exported password vaults.
File encryption flips the model. The file stays encrypted everywhere it is stored and only becomes readable on the machine where you decrypt it, for as long as you need it. A PDF encrypted with your public key and copied to three cloud drives is unreadable at all three destinations. The weak point moves from the storage to your own secret key, which is where you actually have some control.
The commands, concretely
GnuPG encrypts a file to a recipient key:
gpg --encrypt --recipient you@example.com --output taxes.pdf.gpg taxes.pdf
The .gpg output is binary. If you need to email the file or move it through a system that mangles attachments, add --armor to get a text-wrapped version, at the cost of roughly a third more size. Decrypting:
gpg --decrypt --output taxes.pdf taxes.pdf.gpg
You will be asked for your passphrase, and the plaintext lands next to the encrypted file.
Two flags matter more than people expect. First, always pass --recipient with your own address rather than a key ID you copied from somewhere; if you have multiple keys, matching on the address surfaces the wrong-key mistake immediately. Second, use --encrypt --sign rather than bare --encrypt for anything you archive. Signing means that in five years, when the question is whether you or someone else produced that file, the signature answers it. Encryption without a signature protects confidentiality but says nothing about origin.
Backups: encrypt before they leave the machine
The classic mistake with backups is trusting the destination. An encrypted archive uploaded to a storage provider is safe only if the encryption happened before the upload, with a key the provider never sees. The pattern:
tar czf backup.tar.gz documents/ && gpg --encrypt --recipient you@example.com --output backup.tar.gz.gpg backup.tar.gz && rm backup.tar.gz
Now upload the .gpg file wherever you like. Restoring is the same steps reversed: gpg --decrypt, then tar xzf. Test the restore path once before you depend on it. An untested backup is a hope, not a backup, and the failure mode here is quiet: a mistyped recipient when the archive was made produces a file you can never open, and you will not discover that unless you rehearse the recovery.
One habit worth adopting for backups specifically: use a second key pair held on paper or a hardware device as an additional recipient. Encrypt to both your daily key and the offline key:
gpg --encrypt --recipient daily@example.com --recipient backup-key@example.com --output backup.tar.gz.gpg backup.tar.gz
If your daily key is ever lost, a compromised laptop cannot lock you out of your own history, because the offline key can still decrypt every archive.
What about whole-disk encryption?
Full-disk encryption (FileVault, BitLocker, LUKS) protects a machine that is off or locked. It does nothing for files that leave the machine: an archive emailed to your accountant, a resume uploaded to a job portal, a spreadsheet in a shared cloud folder. The two layers solve different problems and most people who handle sensitive files eventually run both.
Key hygiene is the whole game
Everything above assumes your secret key is protected. Three practices carry almost all the weight. Keep the primary key offline or on a hardware token and use a subkey for daily work, so a malware incident costs you a revocation and a reissue rather than your identity. Give the primary key an expiry date you actually renew; an expired key that falls into the wrong hands is a smaller problem than an eternal one. And generate a revocation certificate now, while the key is healthy, and store it somewhere separate from the key itself. If you are staring down a lost or dead key instead, our piece on key expiration, revocation and lost keys covers what still works.
If you are new to PGP and do not yet have a key pair, the fastest path is the free generator on the EasyPGP home page, which creates a key pair entirely in your browser without sending the secret key anywhere. From there, our walkthrough of sending an encrypted email covers the key exchange step, which is the same one you need before sharing encrypted files with anyone else.
The point
File encryption is not about more secrecy for its own sake. It is that storage stopped being a place you control. Documents now live on laptops that travel, in accounts that get phished, and on services that get breached. Encrypting at the file level means none of those events expose anything readable, and the only thing an attacker gets from your backup archive is a block of noise with your name on the envelope.