How to send a PDF securely

By Nick ·Updated 27 July 2026

"Send this securely" covers four different jobs: password-protecting the file itself, encrypting it in transit, controlling what happens after it arrives, and knowing whether it was actually opened. No single method does all four. This guide walks through each option - built-in PDF passwords, email, cloud storage links, and tracked link sharing - with honest tradeoffs and the steps for the tools you already have.

What does "securely" actually mean for a PDF?

Before picking a tool, it helps to name the risk you actually care about. Most people sending a contract, proposal, or report are worried about one or more of these four things:

Interception: someone reading the document on its way to the recipient.
The wrong recipient: a mistyped address, a forwarded email, a link shared onwards.
Loss of control after delivery: the copy that lives forever in someone's downloads folder, long after the deal changed.
Not knowing: you cannot tell whether the document arrived, was opened, or was read past page two.

Different methods defend against different subsets of this list. A password-protected file defends against interception and the wrong recipient, but not against loss of control. An email attachment defends against almost nothing on its own. A hosted link is the only approach that addresses the last two, because the document stays somewhere you can still reach it. It is also worth being honest about what nothing prevents: a recipient who can read a document can always photograph the screen. Real-world PDF security is about controlling distribution and keeping evidence, not about making reading physically impossible.

Should you password-protect the PDF file itself?

Every serious PDF tool can encrypt the file with a password, so this is the approach most people try first. Done with a modern tool, it uses real AES encryption: without the password, the file is unreadable no matter where the copy ends up.

Here is how in the common tools:

Adobe Acrobat: All tools → Protect a PDF → Protect with password → choose viewing password, save.
macOS Preview: File → Export → tick Encrypt, set a password. (Recent macOS versions use strong encryption; very old exports used weaker ciphers.)
Microsoft Word: when exporting to PDF, choose Options → Encrypt the document with a password.
LibreOffice: File → Export as PDF → Security tab → set open password.

The tradeoffs are real, though. You now have a second secret to deliver, and it must travel by a different channel than the file - a password in the same email defeats the point; text it or say it on a call instead. The protection is also static: once someone has the file and the password, they have it forever, and you cannot revoke, expire, or update the document. Old tools that encrypt with the legacy RC4 cipher (rather than AES-256) offer far weaker protection than the padlock icon suggests. And there is recipient friction - a mistyped password on a phone is often where "secure" delivery quietly fails.

Is an email attachment ever the secure option?

Email is where most PDFs travel, so it is worth being clear-eyed about what it does and does not protect. Between major providers, email is encrypted in transit (TLS) - interception is not the main risk. The problems are everything else: a copy now exists on your mail server, the recipient's mail server, and every device that syncs either mailbox. You cannot un-send it, you cannot expire it, forwarding is one click, and you get no signal about whether it was even opened. Attachments also hit size limits around 20-25 MB.

The mainstream providers offer partial fixes:

Gmail confidential mode: compose → toggle confidential mode → set an expiry and optional SMS passcode. The recipient cannot forward, copy, or download - but it works by replacing the attachment with a link to Google's servers, screenshots remain trivially possible, and there is no read analytics.
Outlook / Microsoft 365 encryption: Options → Encrypt (or "Do Not Forward"). Solid inside organisations that both use Microsoft 365; clunky for external recipients, who may need a one-time passcode flow.

A sensible rule: an attachment is fine when the document is not sensitive, the recipient is certain, and you do not care what happens next. For anything else, combine email with one of the other methods - either attach an encrypted file, or (usually better) email a link instead of the file. If knowing whether it was read matters to you, see our companion guide on tracking a PDF sent by email.

When is a cloud storage link (Drive, Dropbox) enough?

Sharing from Google Drive, Dropbox, or OneDrive fixes email's worst problem: the file stays in one place you control. Restrict access to specific email addresses (in Drive: Share → add people, and turn link access off; in Dropbox: Share → specific people), and you can revoke access or replace the file later. That is genuinely more secure than an attachment.

The limits show up at the edges. "Anyone with the link" mode - which is what people actually use, because per-address permissions force recipients to sign in with the matching account - is only as secure as the least careful person the link reaches. Download blocking is patchy across apps and platforms. And visibility is thin: Dropbox shows basic view events on some plans, Drive tells you almost nothing. For a personal document shared with someone you trust, a restricted cloud link is enough. For a business document where you need certainty, it usually is not.

What is tracked link sharing - and when is it the better tool?

The fourth approach is a category built for exactly this job: document-sharing services such as EveryPage, DocSend, or Papermark. You upload the PDF once and send a link. The document never leaves the server - readers view it in the browser - so control survives delivery: you can require a password (entered on the page, not baked into a file), gate the document behind an email address, watermark every page with the viewer's identity, block downloads, expire the link on a schedule or after a number of views, and replace or kill the file behind the link at any time.

The same architecture is what makes the fourth risk - not knowing - solvable. Because reading happens on the page rather than in a downloaded copy, the link can report back: who opened the document, how far they got, how long they spent on each page, whether they came back. That turns "sent securely" into "sent securely, and read on Tuesday, twice, with four minutes on the pricing page." How that works under the hood is covered on our PDF tracking page.

The tradeoffs, honestly stated: the document lives with a third party, so the provider's own security posture matters (encryption at rest, what they log about your readers - EveryPage, for instance, stores no reader IP addresses and encrypts files with AES-256-GCM). Readers need to be online. And nothing client-side can truly prevent a determined person photographing a screen - watermarking exists to make that traceable rather than impossible.

Which method should you choose?

Match the tool to the risk, not the other way around. Two habits do more for document security than any product choice: never send a password in the same channel as the file it unlocks, and prefer a link you can still control over a copy you can't. With that in mind:

One-off file to a trusted person, no follow-up needed: password-protect the PDF (AES), send the password by a second channel.
Internal documents inside a Microsoft/Google organisation: your suite's built-in encryption and permissions are the low-friction choice.
Casual sharing where revocation would be nice: a cloud storage link restricted to named people.
Proposals, decks, contracts, reports - anything where control after delivery or knowing it was read matters: a tracked link with a password or email gate, expiry, and watermarking as the stakes demand.

The methods also combine. Many senders email a tracked link (the email is just the envelope; the document and its rules live on the server), or keep a password-protected copy for archival while sharing the working version as a link. What rarely makes sense is the default most people fall back to: a naked attachment with none of the above, sent and hoped for.

How do you send a PDF securely with EveryPage?

Upload your PDF at everypage.co - it is encrypted with AES-256-GCM before it touches disk, and no account is needed to try it.
On the configure step, set the rules the document calls for: a password, an expiry date or view budget, downloads on or off, an email gate or per-viewer watermark for the sensitive cases.
Send the link (or QR code) however you normally would - the secrets stay on the server, not in the URL.
Watch the readership report: who opened it, how far they read, who came back. If something leaks or changes, expire the link and the document dies with it.

The full protection stack - passwords, screenshot deterrence, expiry, watermarking, encrypted storage - is laid out on the secure PDF sharing page.