Learn to encrypt file with gpg: A Simple Guide

You’re probably here because a file can’t just be “private enough.”

It’s a contract draft headed to outside counsel. A manuscript with tracked revisions. A PDF full of employee data, audit notes, or regulated records. Emailing that file as an attachment without encryption leaves too much to chance, and password-protecting the PDF itself often doesn’t solve the core issue. You also need to know who sent it, whether anyone altered it, and whether the recipient can verify that before they act on it.

That’s why teams still use GPG. It’s one of the few tools that works cleanly at the command line, fits into repeatable workflows, and handles more than secrecy. If you learn to encrypt file with gpg properly, you’re not just locking a document. You’re building a workflow for confidentiality, authenticity, and integrity.

Why GPG is Your Digital Fortress for Sensitive Files

A legal team finishes a redlined agreement late in the day. The final PDF needs to go to opposing counsel, but the sender also needs proof that the document came from the right person and wasn’t modified between export and review. A publisher has a revised manuscript moving between editor and author. A compliance analyst needs to hand off versioned evidence files without exposing them in transit.

In each of those cases, the file matters, but the chain of trust matters just as much.

GPG solves a real operational problem. It lets you encrypt files so unauthorized people can’t read them, and it also supports signatures so the recipient can check whether the file is authentic. That combination is why GPG stays relevant in legal, publishing, compliance, and security operations. It’s not glamorous, but it works.

Encryption protects confidentiality. Signatures protect trust.

That second piece gets overlooked in shallow tutorials. They show one command, produce a .gpg file, and stop there. In practice, professionals need something stronger. They need a repeatable method for sending sensitive drafts, preserving revision history, and proving a document hasn’t been tampered with during transfer.

This is especially clear in industries where document handling is part of the risk surface. If you work around regulated records, transaction documents, or internal approvals, guidance around data security in financial services is useful context because it reflects the broader reality: the document itself is only one part of the control. Handling, transmission, validation, and auditability matter too.

GPG gives you that broader control set. The commands are straightforward. The discipline around them is what separates a safe workflow from a false sense of security.

Generating and Managing Your GPG Keys

Before you can encrypt for others or sign anything, you need a key pair. Think of it as your cryptographic identity. The public key is what you share so others can encrypt files to you. The private key stays under your control and is what lets you decrypt files and create signatures.

Generate your first key pair

Start with the interactive generator:

gpg --full-generate-key

You’ll be prompted for several choices. If you’re new to GPG, keep the decision-making simple and intentional.

1. Choose the key type Pick RSA and RSA if that’s offered in your environment. It’s widely supported and easy to understand in mixed-team workflows.

2. Choose the key size Use 4096 bits. That’s a common professional default because it gives strong security without making routine use awkward.

3. Set an expiration date Don’t leave this as an afterthought. Expiring keys is a practical control. It forces periodic review and supports cleaner rotation if someone changes roles, leaves a project, or a key needs to be replaced.

4. Enter your identity Use the name and email address that colleagues will recognize. If your key says one thing and your documents come from another identity, users will hesitate, or worse, skip verification.

5. Protect the private key with a strong passphrase The private key is the crown jewel. If someone gets it and also gets the passphrase, they can decrypt files intended for you and sign content as if they were you.

Check what keys you have

Once generated, verify that the key exists in your keyring.

gpg --list-keys

That shows public keys you’ve stored locally, including your own public identity and any colleagues’ keys you’ve imported.

To see the private keys available on your machine:

gpg --list-secret-keys

If a command later fails because GPG says it can’t find a secret key, this is one of the first checks to run. It tells you whether the decryption or signing key is present on the system you’re using.

Export your public key

To let others encrypt files for you, export your public key in ASCII-armored form:

gpg --export --armor your-email@example.com > publickey.asc

The --armor flag matters when you need a text-safe format for email, chat, ticketing systems, or documentation. A plain binary export is fine for some workflows, but armored output is easier to distribute without corruption.

Import a colleague’s public key

When someone sends you their public key file, import it like this:

gpg --import colleague-publickey.asc

Then list keys again and confirm the key is present. Don’t treat import as trust by default. A secure workflow includes verifying that the key belongs to the person you think it does. Teams usually do that through an established internal channel.

Operational habit: Keep a small internal record of whose key belongs to which person and when it was last verified. That saves confusion later when staff rotate or projects overlap.

Key management habits that save pain later

A few habits make GPG far easier to live with:

• Back up your private key securely. If the machine dies and the private key is gone, your encrypted archives may be unrecoverable.
• Store your revocation certificate before you need it. If a key is lost or compromised, you need a clean way to tell others to stop trusting it.
• Use recognizable user IDs. Shared project aliases cause confusion. Named identities are easier to validate.
• Keep keys organized by purpose. Personal experimentation and production work shouldn’t live in a messy, indistinguishable keyring.

Most GPG problems aren’t caused by bad cryptography. They’re caused by weak operational hygiene around keys.

Choosing Your Encryption Strategy Symmetric vs Asymmetric

A contract draft, a manuscript revision, and a compliance report do not all need the same GPG workflow. The right choice depends on who must read the file later, who must prove authorship, and how much key handling your team can realistically maintain.

Symmetric encryption

Symmetric encryption protects a file with one shared secret: the passphrase. In GPG, that is the -c mode. As Red Hat explains in its GPG overview, this method derives the encryption key from the passphrase and works best when one person controls the file or when a separate secure channel already exists for sharing that secret.

Use it for cases like these:

• personal archives you will reopen yourself
• offline backups on removable media
• one-off transfers where the recipient already has a safe way to receive the passphrase

The trade-off is operational, not mathematical. Symmetric encryption is quick to start, but the moment two or three people need access, you are now managing a shared password. That creates copy-and-paste risk, chat history exposure, and the usual confusion about who still knows the secret after a project ends.

Asymmetric encryption

Asymmetric encryption uses public and private keys. You encrypt to a recipient’s public key, and only the matching private key can decrypt the file.

This is usually the better choice for professional document handling. It fits real workflows better. Contract reviewers, editors, legal staff, and finance teams can receive protected files without anyone passing around a reusable password.

It also gives you cleaner access control:

• You encrypt to specific identities
• You can add multiple recipients without exposing one common secret
• Offboarding is easier because you stop encrypting to a former employee’s key instead of changing a password everyone shared
• Signing fits naturally into the same workflow, which matters if the document’s origin and revision history need to be defensible

If your team needs a broader process for secure exchange, this approach lines up well with guides that show how to encrypt and share files like a pro.

Side-by-side decision guide

The mistake that causes recovery problems

A common failure shows up months later. Someone encrypts a file only to the external recipient, archives the sent copy, and later discovers they cannot reopen it because their own key was never included.

If you expect to read the file again, encrypt it to the recipient and to yourself.

That matters in ordinary business work. Lawyers reopen executed drafts. Editors revisit submission packages. Security teams preserve evidence bundles for later review. Encryption is only half the job. You also need a workflow that supports retrieval, verification, and attribution after the file leaves your hands.

What usually works best

Symmetric encryption is fine for solo storage and short-lived personal protection.

Asymmetric encryption is the better default for collaboration, versioned document review, and any process where authenticity matters alongside confidentiality. It asks for more setup up front, but it prevents the larger mess of shared passphrases, unclear ownership, and files nobody can confidently verify later.

Encrypting and Decrypting Files A Command-Line Walkthrough

This is the section of interest. The good news is that the commands are short. The better news is that they’re predictable once you know which mode you’re in.

These commands work naturally on Linux and macOS. On Windows, use Gpg4win or run GPG through WSL if your team prefers a Unix-like shell.

Encrypt a file with a passphrase

If you want quick protection for a file you’ll decrypt yourself later, use symmetric mode:

gpg -c document.pdf

GPG prompts you for a passphrase and creates an encrypted output file, usually with a .gpg extension.

What the flag means:

• -c tells GPG to use symmetric encryption.

To decrypt that file later:

gpg --decrypt document.pdf.gpg > document.pdf

This writes the decrypted content back to the original filename. If you’re working carefully, choose a new output name first so you don’t accidentally overwrite a file you still need.

Encrypt a file for a recipient

In professional handoffs, you’ll usually encrypt to someone’s public key:

gpg --encrypt --recipient person@example.com document.pdf

What the flags mean:

• --encrypt starts public-key encryption
• --recipient selects the public key in your keyring
• document.pdf is the plaintext input file

This command creates an encrypted file that the recipient can open with their private key.

If you also need to reopen the file yourself, include your own identity too:

gpg --encrypt --recipient person@example.com --recipient your-email@example.com document.pdf

That one line prevents a lot of regret.

Field rule: If you send an encrypted file and expect to archive it, encrypt to the recipient and to yourself.

To decrypt a public-key encrypted file:

gpg --decrypt document.pdf.gpg > document.pdf

GPG will locate the matching private key in your keyring and prompt for that key’s passphrase if needed.

Use ASCII armor when transport is messy

Some systems don’t handle binary attachments gracefully. If you’re moving encrypted output through text-oriented channels, armored output helps:

gpg --encrypt --armor --recipient person@example.com document.pdf

That creates ASCII-armored ciphertext, which is easier to pass through email or systems that don’t like binary blobs.

If you want a broader practical primer beyond the commands here, this guide on how to encrypt and share files like a pro is a useful companion for thinking through handling and transfer decisions around sensitive files.

A quick note on directories and archives

GPG encrypts files, not folders. If you need to protect a directory of drafts, exhibits, or manuscript assets, archive it first with a tool like tar, then encrypt the archive. That keeps the workflow predictable and reduces the chance of missing loose files.

A short walkthrough can help if you want to see the commands in action:

What to check when decryption fails

If gpg --decrypt doesn’t work, the failure usually falls into one of a few buckets:

• Wrong key context: You’re on a machine that doesn’t have the matching private key.
• Wrong recipient choice during encryption: The sender didn’t encrypt to the correct person.
• Missing self-recipient for archived files: The file was sent successfully to others, but not to the sender.
• Passphrase trouble: The private key exists, but the passphrase entered doesn’t grant access.

Most of the time, GPG is doing exactly what it should. The problem is that the intended recipient list or key availability wasn’t thought through before the file left the machine.

Ensuring Document Authenticity with Digital Signatures

You send a redlined contract for approval on Friday. On Monday, the other side returns a file with the same name, a few clauses changed, and no clear way to prove whether those edits came from your team or theirs. Encryption would have protected the file in transit. It would not have answered the harder question: is this the exact document you signed off on?

That is the job of a digital signature.

GPG signs a cryptographic hash of the file with your private key. Anyone with your public key can verify two things: the file has not changed since you signed it, and the signature was made by the holder of the matching private key. That is what makes GPG more than a file-locking tool. In contract review, manuscript submission, policy signoff, and versioned data exchanges, you need privacy, proof of origin, and a way to detect silent edits.

For file workflows, I usually recommend a detached signature because it keeps the document unchanged and creates a separate proof file.

gpg --detach-sign document.pdf

That command creates document.pdf.sig. The recipient verifies it against the document they received:

gpg --verify document.pdf.sig document.pdf

Detached signatures fit professional review processes well. Legal teams can keep the original PDF intact. Editors can verify a manuscript without altering its format. Compliance staff can store the signature as a separate artifact in the audit trail. A practical walkthrough from Yan Han also highlights detached signatures as a useful approach in normal GPG file handling workflows, especially when you want verification without modifying the original document format (Yan Han).

Verification needs to happen every time the file matters. In practice, many users skip that step and assume encryption alone is enough. That leaves room for the wrong attachment, an unauthorized revision, or a substituted file to pass through a trusted channel.

A simple operating pattern holds up well under review:

• Sign before handoff: Generate the detached signature from the exact version you intend to approve, publish, or share.
• Send both files together: The document without the signature is only half the package when authenticity matters.
• Verify before acting on the content: Review, approval, publication, and downstream processing should wait until the signature check passes.
• Store evidence when needed: For contracts, regulated records, or controlled revisions, keep the verified file, the .sig file, and a record of who validated it.

If the document moves by email, combine signatures with broader essential email security best practices. Email can move the file. The signature proves whether the file still deserves trust.

Common Pitfalls and GPG Best Practices

Most GPG mistakes come from routine habits, not from the encryption engine.

A short checklist fixes most of them.

The mistakes to avoid

• Forgetting key lifecycle planning: Create and securely store a revocation certificate early. If a key is lost or compromised, you need a way to revoke trust cleanly.
• Using a weak passphrase on the private key: A strong key protected by a weak passphrase is still an operational failure.
• Skipping private key backups: If the key disappears with a dead laptop, old encrypted files may become inaccessible.
• Ignoring recipient selection: Before you encrypt, confirm exactly who needs decryption capability.
• Using binary output where text-safe transfer is required: Add --armor when the file may travel through email or text-heavy systems.

Quick fixes for common friction

If you hit secret key not available, don’t panic. Check whether the expected private key exists on that machine, whether you’re using the right user account, and whether the file was encrypted to that identity.

If someone says they can’t open a file you sent, check the recipient value you used during encryption before assuming the file is corrupted.

ASCII armor is often the difference between a clean transfer and a mangled attachment in older or restrictive systems.

The durable habit

Use GPG as a workflow, not a one-off command. Generate keys carefully, verify who owns each public key, encrypt to the right recipients, and sign files when authenticity matters. That’s how you encrypt file with gpg without creating a support problem for your future self.

If your team encrypts and signs sensitive PDFs, you still need a reliable way to review what changed between versions. CatchDiff helps legal, compliance, publishing, and product teams compare PDFs with smart page matching and character-level redlines, so you can spot real edits quickly without the noise that breaks traditional position-based comparison.