How to Password-Protect a PDF (Free, Browser-Based)

Last reviewed: 2026-05-08 — ScoutMyTool Editorial

The U.S. Department of Health and Human Services Office for Civil Rights reported 725 healthcare data breaches affecting 500+ records each in calendar year 2023, and the underlying HIPAA Security Rule §164.312(a)(2)(iv) treats encryption of electronic protected health information as the de-facto standard for "addressable" safeguards — meaning unencrypted PDF attachments are presumptively non-compliant. Sending a contract, a tax return, or a confidential proposal as a plain PDF attachment is the digital equivalent of mailing your bank statement on a postcard. Adding a password takes about thirty seconds and makes the document genuinely confidential — assuming you choose the right kind of password and share it the right way.

This guide covers the two distinct password types defined in the PDF specification, the strongest free encryption methods available, and the small but important details about how to share the password without defeating the purpose. For a free browser-based protection workflow with no signup, our protect PDF tool handles AES-256 encryption in under a minute.

PDF tools

Merge PDFs

Combine multiple PDFs

Compress PDF

Shrink PDF file size

Extract Pages

Pull pages from a PDF

Browse all tools →

Two types of PDF passwords

PDFs support two different password types, and people regularly confuse them. Picking the wrong one can leave a document either annoying to open or accidentally unprotected. Both are formally defined in §7.6 of ISO 32000-2:2020 (the public PDF 2.0 standard).

Open password (also called user password or document password): required to open the document at all. Without this password, the file shows nothing — not even a preview. This is what most people mean by "password-protect a PDF."

Permission password (also called owner password): lets anyone open and read the document, but restricts what they can do with it — printing, copying text, editing, extracting pages. Useful for documents you want widely readable but not modifiable, like a published report or a draft circulated for comment.

Most workflows use one or the other:

Sending a confidential contract by email: open password. Recipient enters the password to read.
Publishing a report you want read but not modified: permission password only. Anyone can open it; nobody can edit or copy.
Maximum protection for a sensitive legal document: both. Open password to access; permission password to prevent printing/copying once opened.

The permission password is genuinely weaker than the open password — readers who can open the document have lots of indirect ways to extract the content (screenshots, retyping, third-party tools that ignore the restriction). Treat permission passwords as a "polite please-do-not" rather than a hard barrier; the academic paper "PDF Security: Permission Bypass" by Müller et al. 2021 demonstrated trivial bypass of the permission password in nearly every PDF reader tested.

How modern PDF encryption actually works

The encryption algorithm matters because PDF supports a range of options, some genuinely strong and some essentially decorative. The PDF 2.0 standard's encryption handlers are listed in §7.6.4 of ISO 32000-2; the underlying AES algorithm is specified in NIST FIPS 197.

RC4 40-bit: ancient, broken, takes seconds to crack with modern hardware per the RFC 7465 RC4 prohibition. Some old tools still use this by default. Avoid.

RC4 128-bit: better, but RC4 itself has known weaknesses — the IETF formally prohibited RC4 in TLS in RFC 7465 and the NIST SP 800-131A Rev. 2 transitions guidance deprecates it for federal use. Considered weak in 2026.

AES-128: solid, widely supported, secure for most purposes per NIST FIPS 197.

AES-256: the current standard. Adobe Acrobat, our protection tool, and most modern free options use AES-256 by default. Computationally infeasible to crack with current hardware if the password itself is strong — the NIST SP 800-131A crypto-transition tables list AES-256 as "acceptable" indefinitely, while shorter keys carry sunset dates.

Brute-force time grows roughly 10¹⁵× from an 8-char lowercase password to a 16-char mixed-symbol password at the same guess rate. Threat model assumes ~10¹¹ guesses/sec — broadly consistent with the 2024 hashcat benchmarks for AES-256-CBC PDF passwords on consumer GPUs. NIST password-strength guidance: SP 800-63B §5.1.1.

The encryption algorithm is only as strong as the password. AES-256 with a six-character password is barely better than no password at all — modern brute-force tools test billions of guesses per second on GPU rigs per the hashcat benchmarks. AES-256 with a 16-character random password is functionally unbreakable.

When choosing a tool, check that it uses AES-256 specifically. If the tool doesn't say, or only mentions "encryption" without specifying, assume the worst.

Step-by-step: adding a password with a browser tool

The fastest free workflow:

Step 1: Open the protect PDF tool in your browser.

Step 2: Drag your PDF into the upload area or click to select.

Step 3: Enter the password you want to use. The tool typically asks twice to confirm.

Step 4: Optional: choose which type of restrictions to apply (printing, copying, editing) if the tool supports permission settings separately.

Step 5: Click "Protect PDF" or equivalent. Processing takes a few seconds.

Step 6: Download the protected PDF. Test it by opening in a fresh browser tab or PDF reader and confirming the password is required.

The whole flow takes under a minute. Always test the protected file before sending — open it, confirm the password works, confirm the restrictions you set are actually in place.

The same upload-based caveat as any browser tool applies: your unencrypted file briefly leaves your computer for processing on some services. For routine confidential documents this is acceptable for most users; for genuinely sensitive material (legal records under attorney-client privilege, classified-equivalent corporate IP), use a desktop encryption tool instead.

Choosing a password that actually protects the document

Password strength is the difference between AES-256 protection and security theater. The math is unforgiving and the NIST SP 800-63B password guidelines recognize this explicitly: a six-character lowercase password has roughly 300 million combinations, which a modern GPU brute-force tool tests in seconds. A 12-character password mixing upper, lower, numbers, and symbols has trillions of trillions of combinations.

Practical rules for PDF passwords:

Minimum 12 characters, preferably 16 or more — consistent with NIST SP 800-63B §5.1.1.2 recommendations
Mix character types: at least one uppercase, lowercase, number, and symbol
Not a dictionary word, even with letter substitutions ("P@ssw0rd" is broken almost as fast as "password" — see the Have I Been Pwned password list which contains over 800 million previously-breached passwords)
Not based on personal information: birthdate, pet's name, address, kid's name. These are guessed first.
Different for each document, especially for sensitive ones. If one password leaks, others stay protected.

The two practical approaches that work:

Random generated password: use a password manager (Bitwarden, 1Password, KeePassXC) to generate something like Tj9#mPqL2vN!8xRk. Store it in the password manager. Share it with the recipient via a separate channel. This is the gold standard for security.

Long passphrase: four to six random words strung together: correct-horse-battery-staple-mountain-river. Easier to type, easier to communicate verbally if needed, mathematically very strong if the words are genuinely random. Avoid quotes from songs or books — those are dictionary attacks waiting to happen. The classic argument for long passphrases is laid out in xkcd 936, and the underlying math (entropy in bits = log₂(wordlist_size) × words) is in NIST SP 800-63B Appendix A.

For one-off PDFs that don't justify a password manager entry, a long passphrase is the most practical option.

Putting the password in the same email as the protected PDF is the single most common mistake. If an attacker compromises the recipient's inbox or intercepts the email in transit, they have both the file and the key — the encryption is doing nothing. The CISA "Implementing Strong Authentication" guidance explicitly calls out separate-channel credential delivery as a fundamental control.

The principle is simple: send the file and the password through different channels. Some practical patterns:

Email the PDF, text the password: works for one-on-one sharing. The two channels are usually compromised independently.
Email the PDF, share the password by phone: most secure for high-value documents. The password is never written down digitally on the recipient's side.
Email the PDF, send the password through Signal or another encrypted messenger: good middle ground.
Slack the PDF in a private channel, share the password verbally in a meeting: fine for internal corporate use.
Use a password manager's secure-share feature: Bitwarden Send, 1Password, and others all have one-time-link sharing for passwords specifically.

What not to do:

Same email: defeats the encryption.
Same email thread but later: barely better. Anyone with thread access has both.
Password in the filename: visible to anyone who sees the file listed in a folder.
Password in the email subject line: same issue.

A reasonable rule: if you wouldn't send the password and the file together on a postcard, don't send them in the same digital channel either.

Removing or changing the password later

Two common reasons to remove a password: you no longer need the document protected (maybe it's been published or the deal closed), or the recipient lost the password and you need to re-protect with a new one.

Removing the password requires knowing the current password — there is no legitimate way to remove protection from a PDF you don't have the password to. Workflow:

Step 1: Open the unlock PDF tool in your browser.

Step 2: Upload the protected PDF.

Step 3: Enter the current password.

Step 4: Download the unlocked PDF.

The unlocked file has no encryption — you can re-protect it with a new password using the protect tool again, or leave it unprotected if appropriate.

Changing the password follows the same flow: unlock with the old password, then protect with the new one. There's no single-step "change password" tool because the underlying operation is always "decrypt with old, re-encrypt with new."

If you've forgotten the password to your own PDF, recovery is hard by design. For weak passwords (under 8 characters, dictionary words), brute-force tools sometimes succeed in hours or days. For strong passwords, recovery is computationally infeasible. The realistic options: find where you stored the password (password manager, note, email to yourself), ask whoever might also have it, or accept that the document is permanently locked.

When metadata leakage matters too

Encryption protects the document content, but PDF metadata can leak surprising amounts of information that survives encryption. Things commonly embedded in PDF metadata (the XMP and DocInfo dictionaries documented in §14.3 of ISO 32000-2):

Author name (often the original Word/InDesign author's full name)
Creation and modification dates
Software used to create the PDF (Microsoft Word version, Adobe InDesign version)
Sometimes: file path on the original machine (revealing usernames or directory structures)
Sometimes: edit history if the file went through many revisions

For genuinely confidential documents, strip the metadata before adding password protection. Our PDF metadata tool lets you view and clean metadata fields. The workflow: clean metadata first, then add password protection. The encryption then covers a clean file rather than one carrying identifying information.

Frequently Asked Questions

Q: Is AES-256 actually unbreakable?

A: With current hardware and a strong password, yes — practically speaking. AES-256 has not been cryptographically broken, and brute-forcing a 16+ character random password would take longer than the age of the universe per NIST FIPS 197 parameters and the hashcat benchmarks. The realistic attack vectors are weak passwords, password leaks through other channels, or someone with physical access to a device where the file is open.

Q: Will password-protecting a PDF prevent screenshots?

A: No. Once a reader opens the document, anything visible on screen can be screenshotted. Permission passwords can disable copy-and-paste of text, but they cannot prevent screenshots — that requires platform-level DRM, which standard PDF doesn't have. For documents where screenshot prevention matters, a watermark (the recipient's name or email visible on every page) is the practical deterrent — see our add watermark guide.

Q: Can I password-protect a PDF I received from someone else?

A: Yes — assuming the document isn't already protected with restrictions on editing. Open the file, then use any protection tool to add a password. The new password applies on top of the existing document; if the original had its own protection, your new password adds a second layer.

Q: Do all PDF readers support AES-256?

A: Adobe Acrobat Reader, Apple Preview, and all modern PDF readers (Foxit, PDF-XChange, browser PDF viewers) support AES-256. Very old readers from before 2010 may not — AES-256 in PDF was introduced with PDF 1.7 Extension Level 3 in 2008 per the Adobe PDF reference. If you're sending to a recipient with unknown software, AES-128 has wider compatibility while still being secure for most purposes.

Q: Is there a difference between encrypting a PDF and putting it in a password-protected ZIP?

A: Yes. PDF encryption protects the document directly — the file remains a PDF and the password is required to view content. ZIP encryption wraps the PDF in an encrypted archive — the recipient extracts the PDF first, then opens it normally. ZIP encryption is sometimes weaker (legacy ZipCrypto is essentially broken; only ZIP's AES mode is comparable to PDF AES-256). For a single PDF, native PDF encryption is cleaner.

Q: Does encrypting a PDF satisfy HIPAA?

A: It's a strong control but not by itself a "safe harbor." The HHS HIPAA Security Rule §164.312(a)(2)(iv) treats encryption as an "addressable" implementation specification — meaning it must be implemented if reasonable for the covered entity. AES-256 PDF encryption combined with separate-channel password delivery is widely accepted as meeting that bar; you still need the rest of the Security Rule's administrative and physical safeguards in place.

Q: Can encrypted PDFs be opened on mobile?

A: Yes. Apple iOS Files / Books, Android default PDF viewers, Adobe Acrobat Reader Mobile, and Foxit Mobile all handle AES-256 password-protected PDFs. The recipient enters the password the first time they open the file; behavior is otherwise identical to opening an unprotected PDF.

Bottom line

Password-protecting a PDF takes thirty seconds and is one of the simplest things you can do to genuinely protect a document. Use AES-256 encryption, choose a 12+ character password (random or long passphrase), and share the password through a different channel than the file itself. Remove the password later when it's no longer needed using an unlock tool. The encryption is only as strong as the password and the channel discipline around it.