Convert PDF to Password Protected PDF Before You Send It
By Schema LawPublished Updated
To convert a PDF to a password protected PDF, open the finished file in a PDF program, choose its protect or encrypt option, require a password to open the document, and save a new copy. Give the recipient the password by another channel. The password hides the pages. It does not hide the file name or stop forwarding.
This post is about the copy that leaves the firm: a searchable PDF you made from a client's scans, a converted exhibit, a set of records going back to the person who owns them. It covers when the ethics guidance points toward a password, the steps in software a firm already has, and the limits. It explains how to handle documents and is not legal advice.
When does a client PDF need a password before it leaves the firm?
A client PDF needs a password, or something stronger, when the information is sensitive enough that ordinary email is not a reasonable way to send it, or when the client or the law requires more. The ABA's guidance sets no fixed rule. It asks you to weigh the facts of each transmission.
ABA Formal Opinion 477R opens with the general position: a lawyer "generally may transmit information relating to the representation of a client over the internet without violating the Model Rules of Professional Conduct where the lawyer has undertaken reasonable efforts to prevent inadvertent or unauthorized access." It then states the exception. A lawyer "may be required to take special security precautions to protect against the inadvertent or unauthorized disclosure of client information when required by an agreement with the client or by law, or when the nature of the information requires a higher degree of security."
The opinion names password protection as one of those precautions. For communications that "are sensitive or warrant extra security", it says a lawyer should encrypt the transmission "and consider the use of password protection for any attachments." It also says that "the use of unencrypted routine email generally remains an acceptable method" of communicating with a client. So the opinion does not make a password mandatory for every attachment, and it does not treat a password as enough for every attachment either. It rejects "requirements for specific security measures (such as firewalls, passwords, and the like)" in favor of a fact-specific process.
The opinion is advisory, and your state's rules and opinions control. With that said, here is a way to turn the test into a decision for one outgoing file.
| Question about this file | If yes |
|---|---|
| Does the engagement letter, the client's guidelines or a court order say how documents must be sent? | Follow that instruction. It overrides your own preference. |
| Does a statute or regulation that binds you or the client set a transmission requirement? | Meet it, and note which one. |
| Would disclosure of these pages hurt the client in a way that is hard to undo (medical, financial, immigration, employment, family matters)? | Protect the file. Consider whether a password is enough. |
| Does the recipient share the mailbox with a spouse, an employer or an assistant? | A password sent to that mailbox protects nothing. Use another channel or another method. |
| Is the file routine, such as a hearing notice already on the public docket? | Ordinary email may be reasonable. Record nothing further. |
In a footnote, Opinion 477R cites a Texas ethics opinion as identifying situations in which a lawyer should consider a security precaution, including "sending an email to or from an account that the email sender or recipient shares with others." That situation applies when, for example, a client's only email address is one an assistant or family member also reads.
Adding an open password to a PDF in software a firm already has
Add an open password in whatever PDF program is already on the computer: Acrobat, Preview on a Mac, or Word when the source is a Word file. Each has a setting that requires a password before the document opens. The steps here are taken from each vendor's own help pages, so check them against the version you run.
Work on a copy. Keep the unprotected file in the matter folder, where your document system controls access, and protect the copy that travels.
Adobe Acrobat
Adobe's help page on encrypting PDFs with passwords gives this sequence:
- Select All tools > Protect a PDF.
- In the left panel, select Encrypt with Password under ADVANCED OPTIONS, and select Yes in the dialog box.
- Select "Require a password to open the document".
- Enter the password in the Document Open Password field, select OK, and type it again to confirm.
- Review the security message, select OK, and save the PDF to apply the change.
Adobe's shorter page on adding passwords to PDFs describes a quicker route through Protect with password, where you choose whether the password is for Viewing or Editing. For a file that must stay closed to anyone without the password, Viewing is the choice that matters.
Preview on a Mac
Apple's instructions for password-protecting a PDF in Preview run through the Export command:
- Open the PDF and choose File > Export.
- Enter a new name if you want a protected copy and an untouched original.
- Click the Permissions button and select "Require Password To Open Document". Enter the password and retype it.
- Enter a password in the Owner Password section and retype it.
- Click Apply, then Save.
Apple adds that changes take effect the next time the PDF is opened. The owner password governs printing and changes. The comparison of open passwords and permission passwords explains what each one controls.
Word, when the document started there
Microsoft's page on saving or converting to PDF in Office desktop apps describes an option in Word's PDF export settings called "Encrypt the document with a password". Microsoft says of it: "To restrict access so only people with the password can open the PDF, select this option." When you select OK, Word opens a box where you type and re-enter the password. This suits a Word export you have corrected and now want to send as a locked PDF without opening a second program.
Check the result
Close the protected copy and open it again. A prompt should appear before any page shows. Then open it on a second device with a different PDF reader, because the recipient may not use yours. Rename nothing and delete nothing until both tests pass.
Which encryption setting should a password protected PDF use?
Use AES with the longest key your program offers and the recipient's reader can open. Avoid the oldest setting on any compatibility menu. A password protected PDF is only as strong as the algorithm behind the password, and a compatibility menu, where your program has one, includes older algorithms so that old readers can open the file.
The PDF specification, ISO 32000-1, sets out the options in section 7.6. Its general algorithm encrypts data "using the RC4 or AES algorithms". Table 20 lists the first version of the scheme as using "an encryption key length of 40 bits", and gives the range for later versions: "The value shall be a multiple of 8, in the range 40 to 128." The AES method is marked as arriving in PDF 1.6.
| What the setting says | What the 2008 specification says about it | Use it for a client file? |
|---|---|---|
| 40-bit RC4, or compatibility with the earliest readers | The original scheme, with a key length of 40 bits | No |
| 128-bit RC4 | Key lengths greater than 40 bits were permitted from PDF 1.4 | Only if the recipient cannot open anything newer |
| 128-bit AES | AES was added in PDF 1.6 | Yes |
| A key longer than 128 bits | Not described in the 2008 edition | Yes, after you confirm the recipient's reader opens it |
Three points follow from the table.
Compatibility is a trade. A setting that promises the file will open in very old software gets there by using an older algorithm. Choose the newest setting the recipient can open, and ask them what they use if you are unsure.
The dialog may not name the algorithm. Adobe's help pages on adding and encrypting passwords describe the password types and do not list the algorithm behind each choice. Apple's Preview page does not name one either. If your program shows no algorithm, look in the document's security properties after saving and see whether the method is reported there.
The password matters more than the key length. A long key guarded by a six-letter word is a six-letter problem. Adobe's password security overview recommends "strong, unique passwords" that avoid "easily guessed information such as names or birthdates", and advises against reusing a password across documents. A passphrase of several unrelated words is easier to read out over the phone than a string of symbols.
Password protecting Word and Excel exports of a scanned file
Word and Excel files take their own passwords, set inside Word and Excel. A PDF password does not carry over when the same content is exported as a document or a workbook, so each outgoing format needs its own step. Plain text and CSV files cannot hold a password at all.
Schema Law's export formats include Word, Excel, CSV, JSON, plain text, Markdown and HTML as well as searchable PDF. If you send a client the spreadsheet of their bank statements and the searchable PDF of the same statements, protecting only the PDF leaves the same figures open in the other attachment.
Word
Microsoft's page on protecting a document with a password gives the Windows path as File > Info > Protect Document > Encrypt with Password. Three limits on that page are worth knowing before you choose the password:
- "Passwords are case-sensitive and can be a maximum of 15 characters long."
- "If you lose or forget your document password, Word won't be able to recover it for you."
- The web version of Word cannot password encrypt a document and cannot edit one that is encrypted. A recipient who works only in the browser will need the desktop program.
Excel
Microsoft's page on protecting an Excel file gives the steps as File > Info, then the Protect Workbook box, then Encrypt with Password. It carries two cautions in Microsoft's own words: "Microsoft cannot retrieve forgotten passwords", and "It's not always secure to distribute password-protected files that contain sensitive information such as credit card numbers." Take the second one seriously for a workbook of account numbers. It is a reason to think about a different delivery method for that file.
Formats with no password of their own
CSV, plain text, JSON, Markdown and HTML are plain files. Either do not send them, or send them through a channel that is itself access controlled. If the recipient needs the data and not the format, an encrypted workbook holding the same rows is the simpler answer.
What a password protected PDF still gives away
A password protected PDF still shows its file name, its size, the fact that it exists, and who sent it to whom. It may show its descriptive metadata. Once opened, it is an ordinary file that can be saved, printed, forwarded and photographed. The password never expires and cannot be recalled.
The specification is exact about what encryption covers. Section 7.6.1 of ISO 32000-1 says: "Encryption applies to all strings and streams in the document's PDF file", with listed exceptions. It adds that encryption "is not applied to other object types such as integers and boolean values, which are used primarily to convey information about the document's structure rather than its contents." The tables of encryption dictionary entries later in section 7.6 define a setting, EncryptMetadata, described in these words: "Indicates whether the document-level metadata stream" is to be encrypted. Its default is true. A file can carry the value false, and that metadata is then left readable in a locked file.
A checklist for the outgoing copy:
- File name. "Okafor_psych_eval_2025.pdf" tells a stranger the client, the subject and the year without opening anything. Rename the outgoing copy to something neutral, such as a matter number and a date.
- Email subject and body. These are not part of the PDF and get no protection from it. Keep the description of the contents out of them.
- Document properties. Open the properties panel before you protect the file. Clear a title, author or keywords that say more than you intend. If your program offers a choice about encrypting metadata, encrypt it.
- Forwarding. Anyone who has the file and the password can pass on both. A password controls who can open the file today. It does not control what an authorized reader does next.
- No expiry and no recall. A copy sent in March opens with the same password in five years. If the relationship with the recipient ends, the file stays readable to them.
- No record of opening. A PDF password does not tell you who opened the file or when.
- The password's own trail. A password that sits in the same mailbox as the attachment undoes the work. The rules for sharing a PDF password without defeating it cover the second channel.
A short example. Dana Whitfield, a paralegal, is returning converted pediatric records to a client, Marcus Okafor. She renames the searchable PDF to the matter number, checks the properties panel and removes the scanner's default title, sets an open password, and tests the copy on her phone. She emails the file with the subject "Documents for you" and reads the passphrase to Mr. Okafor on a call to the number in the intake form. The matter log records the date, the channel and the fact that a password was given, and leaves the password itself out.
Pediatric pages like these hold sensitive personal information that a careless file name can reveal before anyone types a password. Client confidentiality reaches the mailbox and the subject line as well as the attachment. Information security for the send is the open password plus a second channel. Record both in the log, and keep the passphrase itself out of the message.
Is a secure link or client portal better than a PDF password?
A secure link or portal is the better choice when you need to end access later, see who opened the file, send many files, or reach a recipient who shares a mailbox. A PDF password is the better choice when the recipient must keep a self-contained copy and has no account anywhere. Neither one is right for every file.
Opinion 477R treats the two as alternatives. After mentioning password protection for attachments, it says: "Alternatively, lawyers can consider the use of a well vetted and secure third-party cloud based file storage system to exchange documents normally attached to emails." The words "well vetted" put the diligence on you, and the opinion lists due diligence on vendors among its considerations.
What a link can do that a file password cannot depends on the product, so read its documentation. As one example, Microsoft's page on sharing OneDrive files and folders describes a "Specific people" setting that "gives access only to the people you specify", an expiration date after which "the link won't work anymore", a link password, and a way to remove a link and stop sharing. The same page notes that the expiration date and password settings are available only to Microsoft 365 subscribers. Check what your own plan includes before you promise a client a feature.
| Need | PDF password | Link or portal |
|---|---|---|
| Recipient keeps a copy that works offline | Yes | Only if downloading is allowed |
| Access can be ended after sending | No | Yes, where the product offers expiry or link removal |
| Recipient has no account and limited patience | One prompt | May require sign-in or a code |
| Many files, or files too large to attach | Awkward | Suited to it |
| Recipient's mailbox is shared | Works if the password goes elsewhere | Works if access is tied to the person |
| The copy must stay locked once it is saved | Yes, the lock is in the file | No, a downloaded copy is unlocked unless the file has its own password |
The last row is the reason to combine them for the most sensitive files: a password protected PDF, delivered through a link limited to the recipient.
Whichever you choose, remember that the copy you hand over may be one the client is entitled to in any case. The post on whether OCR text is part of the client file covers which converted copies go back to the client when they ask for their file. Protecting a copy on its way out does not change who it belongs to.