Restrict PDF editing and printing, and know what it really stops

Set the restrictions: the steps

1. Open Protect PDF above and drop your PDF, for example the quote or certificate you are about to send. Several files at once work too.
2. Leave Password to open empty if everyone may read the file. Fill it in only if the content itself is private.
3. Type an Owner password. Make it different from the password to open: if both are the same, whoever opens the file is the owner and every restriction is lifted for them. We measured it: a file with all 4 permissions unticked and 1 shared password reports everything allowed once that password opens it. The field’s hint says so before you click, and the result warns about it if you do it anyway.
4. Under Allow, untick what readers may not do. The tick boxes start all on.
5. Press Protect. The report says “Restricted:” followed by what you turned off, in the boxes’ own words (printing, changes, copying text, notes and form filling); Download PDF saves yourfile-protected.pdf.
6. Keep the owner password somewhere safe, such as a password manager. You need it, or Unlock PDF, to change the file yourself later.

Everything runs on your device; nothing is uploaded. The file is encrypted with AES-256 even without a password to open, because the permissions travel inside the encryption settings, but any viewer can decrypt it with the empty password.

What each tick box asks for

The PDF format has a few more permission bits than the 4 tick boxes; each box sets the related ones together.

Who honours the flags, and who does not

The specification leaves enforcement to each program. We checked the source code of 2 common viewers and ran our own tools, on 11 October 2026:

• Chrome’s built-in viewer honours print and copy: its code checks the print bit and the copy bit before it allows either (Chromium, pdf/pdfium/pdfium_permissions.cc).
• Firefox’s built-in viewer ignores them by default. Its option pdfjs.enablePermissions is off unless an administrator switches it on by policy (pdf.js, web/app_options.js; Firefox’s policy documentation).
• getPDF’s own tools ignore them. On a file with all 4 permissions denied, Merge, Compress and PDF to Text all ran without asking, and the results came out with no protection at all. Merge says “1 file was password-protected; the result is not.” Unlock PDF removes the restrictions in 1 step, without any password.

We tell you this because a false sense of protection is worse than none. Restrictions stop an honest reader from printing by habit or editing by accident. They do not stop anyone who has decided to.

What serves the real goal better

A note on signatures: getPDF’s signing creates simple electronic signatures (drawn, typed or an image) and does not create certificate signatures yet. If you need tamper proof, that has to come from a certificate provider; the signing and filling guide explains the difference.

Flattening is not protection either: the text stays readable and copyable, and an editor can still change the page. It removes the easy route of retyping a field, nothing more.

When the flags still earn their keep

• Honest recipients. A client who opens your quote in Chrome cannot print an old version by habit or edit the price by accident.
• Office workflows. “Final, do not change” becomes something a program can read, not just a line in an email.
• A signal. A restricted file tells the reader you did not expect it to be changed, which matters if it later turns up changed.

The honest part

If a document must provably not change, permissions are the wrong tool entirely; use a certificate signature and keep the original. If its content must stay private, use a password to open. Restrictions cannot stop a screenshot, a phone camera, or any tool that does not care, ours included. For the 2 passwords side by side, read user vs owner password; the wider map is in the PDF privacy and protection guide.