Confirm that the Preview procedure matches your iPhone
Apple documents a Lock action in Preview on iPhone. Check the version selector in its guide against your device. If Preview or Lock is missing, this particular route does not match your setup; do not assume an identically named control exists in Books, Notes or another reader.
Start with a harmless sample PDF containing a recognizable word. Decide whether you need to protect a file for storage, prepare an attachment or organize several documents. For this first exercise, keep private records out of the sample and leave your important originals unchanged.
Name the copy you intend to protect
Before changing anything, record the filename and its location. A useful label might be “sample PDF, copy to check.” Apple provides Duplicate in the filename actions menu if you need a separate copy before applying protection. That duplicate creates another item to track.
Keep a short inventory: original location, working copy, intended destination and check result. Leave unknown entries marked “not checked.” Renaming a file helps identify it; the name itself is not evidence that a password was applied. Avoid names containing the password or private document details.
Apply the password to the selected PDF
Open that PDF in Preview. In the actions menu beside its filename, choose Lock. Enter the same password in Password and Verify, confirm that Require Password is enabled, and apply the change. Apple’s current guide says the switch turns on automatically. Follow the controls shown for your version.
Keep the password in a place you can access when needed, separate from the filename and any checklist you share. Before using an important document, ask whether you could still find that secret if this phone were unavailable. A saved file and an available password are separate things to verify.
Reopen the saved file rather than trusting its name
Return to the file’s saved location and reopen the specific copy you identified. Observe whether the reader requests its password and whether the password you retained opens it. If an already open session hides that step, record the result as incomplete and repeat in a suitable fresh opening context.
Check recognizable content and page count against the sample. Record three outcomes: correct copy found, password behavior observed and expected pages readable. This is a proposed validation method, not a device test we performed. An ambiguous result is a reason to investigate before relying on the copy.
Check the attachment you actually plan to send
For sharing, repeat the exercise with the harmless PDF and your intended transfer route. Open the received copy in the reader you plan to use and repeat the checks. Record its filename and destination so that success on a local working copy is not confused with success on the attachment.
Do not put a real password in a public demonstration or send a confidential document merely to test compatibility. If the received result differs, retain the originals and examine which file was selected and whether the transfer changed its format. This guide makes no promise about every app or recipient’s reader.
Keep the remaining limits visible
Finish with a precise note, such as “saved copy reopened; sharing route not checked.” A password action does not establish the location or protection of every earlier duplicate, scan or attachment. Review those items separately, and preserve a verified readable copy before considering any cleanup.
The cited iPhone procedure does not establish a forgotten-password recovery route, an encryption-strength rating or protection against every threat. Do not infer those properties from the word Lock. If you need a collection-level workflow, compare access, export, recovery and backup separately using the related vault-selection guide.