PDF Permissions Explained: Printing, Copying, Editing and Viewing

Table of Contents

1. Permissions are requests, not locks
2. Where the permission bits live
3. The permission flags, one by one
4. Print and print at high quality
5. Copy and extract
6. Modify, annotate, fill forms and assemble
7. Owner password and user password, revisited
8. How viewers enforce permissions, unevenly
9. How owner-password restrictions are bypassed
10. What permissions are good for
11. Setting and checking permissions
12. Practical guidance for legal, IT and admin teams

Permissions are requests, not locks

The first thing to understand about PDF permissions is that they describe what the document's creator intends. They do not reliably enforce that intention. ISO 32000 defines a set of permission bits, and it relies on conforming applications to respect them. A conforming reader that finds the print bit cleared is expected not to print the document. A reader that finds the copy bit cleared is expected not to copy text. But the specification does not turn the file into something that cannot be printed or copied by an application that ignores the bits.

This distinction runs through everything in this article. Readers who know the difference between a rule that a compliant program follows and a barrier that stops an adversary will get far more value from PDF permissions. Readers who assume a permission is a lock will be disappointed the first time a colleague uses a free tool to strip it.

Permissions also have a narrower scope than many people expect. They control actions a viewer may perform on the document as opened. They do not control who may open the document. That job belongs to the user password, which we cover in our article on how to encrypt a PDF file.

Where the permission bits live

The permission flags are stored in the /P entry of the encryption dictionary, as a signed 32-bit integer. Each bit represents one permission. A bit that is set to 1 grants the corresponding operation to a conforming application, and a bit that is set to 0 denies it. Several bits are reserved, and the specification requires them to hold particular values, which is why the integers you see in tools often look like negative numbers or like large values with many high bits set.

The /P value is also part of the key derivation for many encryption revisions. That means it is protected by the file's encryption in a meaningful way. Changing it without the owner password and then re-saving the file in a way that keeps the encryption intact is not possible for a simple text edit. This is why tools that remove restrictions usually decrypt the file first, which we return to below.

For AES-256 files written to PDF 2.0, a copy of the permissions is also stored in an encrypted Perms entry, which lets a reader verify that the /P value has not been altered. That verification is one of the reasons modern files are harder to tamper with than old ones, although it does not change the basic fact that an application with the key can decrypt and rewrite the file.

The permission flags, one by one

The following table lists the flags defined in ISO 32000 for the Standard Security Handler. The bit positions are numbered from 1 to 32, with bit 1 as the least significant bit in the specification's convention. The values are the decimal values of the bit when it is set.

Bits 1 and 2 are reserved and must be zero. Bits 7 and 8 are reserved and must be one in the typical implementation. Bits 13 to 32 are also reserved, and writers conventionally set them to one. This is why a typical permissions value looks like a large negative integer. The exact value is not a meaningful indicator on its own; the bits you care about are the ones described above.

Two points about the table. First, the print bit and the high-quality print bit are separate. A document can permit low-resolution printing and block high-quality printing, which some readers implement and some do not. Second, the accessibility bit is distinct from the copy bit. ISO 32000 provides the accessibility extraction flag so that assistive technology can read a document even when general copying is blocked. Many public-sector accessibility obligations assume that carve-out exists.

Print and print at high quality

Print is the most visible permission and the one most often expected to be enforced. When it is cleared, a compliant viewer disables the print command, or prints only at a degraded resolution if the print bit remains and the high-quality bit is cleared.

The distinction between low- and high-quality printing is implemented unevenly. Some viewers allow only low-resolution output when the high-quality bit is cleared, and others ignore the high-quality bit entirely. Test the combination you intend to use. A restriction that is ignored by a viewer used by a few recipients is not a restriction for those recipients.

Print restrictions are also easy to bypass by means that have nothing to do with the viewer's print command. A recipient can take a screenshot of each page, or can use an operating system print-to-PDF function, which renders the document through a printing pipeline that the viewer may not treat as a print operation for permission purposes. Whether that path respects the bit varies by product and version. Do not rely on print permissions to prevent a determined recipient from producing paper or digital copies.

Copy and extract

The copy flag, formally the bit for extracting text and graphics, controls whether a viewer allows text selection and copy-and-paste, and whether it allows the content to be exported. In most mainstream viewers, when this flag is cleared, the selection tool becomes inactive or the copy command is disabled.

Copy restrictions have a particular weakness. Text in a PDF is stored as glyph instructions and usually as text objects that a reader can extract. A tool that reads the page content directly, including open-source command-line tools, can extract the text regardless of the copy flag once the file has been decrypted. Optical character recognition on a screenshot does the same job for scanned or image-based pages, even without access to the underlying text.

The accessibility bit is the exception that matters for inclusion. Screen readers and other assistive technology must be able to extract content when that bit is set, even if the general copy bit is cleared. If you are restricting copy for a client, check that the accessibility flag remains set, so that the document still works for users who depend on it. The W3C Web Content Accessibility Guidelines and national procurement rules that reference them make this a practical expectation in many organizations.

Modify, annotate, fill forms and assemble

The modify flag controls whether a viewer allows changes to the document's content. In most editors, this means the editor will refuse to save edits to the page content, and in some it will refuse to open the file for editing at all. Editing is not the same as annotating, so the annotation flag is separate. It allows or denies the addition and change of text annotations, comments and some markup.

The fill-forms flag controls whether users may enter data into existing form fields and, in many implementations, whether they may apply digital signatures to those fields. A document can therefore allow form filling while denying other changes, which is a common arrangement for applications and contracts that must be completed by a third party.

The assemble flag covers operations that change the document's page structure: inserting pages, rotating, deleting pages, creating bookmarks and thumbnail images. A document that permits editing content but denies assembly can be corrected in place without being reorganized, which some legal teams find useful when they want a specific version of a document to remain intact.

These flags have an important limitation in practice. A viewer that supports editing may allow an edit that the flags would have blocked, if the user is the document's owner or has the owner password. Editing software is also very capable of rewriting a PDF from scratch, so a flag that blocks in-place editing does not block a full re-creation of the document from its source file.

Owner password and user password, revisited

The owner password is the key to the permission system. In the Standard Security Handler, the owner password is used to derive the key that controls changes to the permissions. A viewer that knows the owner password will open the document with all permissions granted, regardless of the flags.

The user password is different. It gates opening the file, so it is a confidentiality control. Permissions are not a confidentiality control, because a file opened with only an owner password, or with a blank user password, is readable by anyone.

This leads to the most common pattern that IT teams encounter. A file is protected with an owner password and no user password. The file opens for everyone, and the creator sees a set of restrictions in their editing tool that prevent printing and copying. The recipient opens the file in a viewer that honours the flags and finds those features disabled. This looks like protection, but the file has no confidentiality at all, and the restrictions are advisory.

Make the distinction explicit in your policies. Confidentiality requires a user password or another mechanism that controls access to the decrypted content. Permission restrictions require an owner password and compliant readers. Some documents need one, some need both, and some need neither, but the choice should be deliberate.

How viewers enforce permissions, unevenly

The enforcement behaviour of the major viewers is not uniform, and it has changed across versions. The following observations are general and should be verified against the versions your recipients use, because vendors update behaviour without much notice.

Adobe Acrobat and Acrobat Reader are the reference implementations for PDF permissions, and they enforce the flags most consistently. They disable the commands the flags block, and they show the restriction state in the document's properties. Acrobat also distinguishes between the owner and the user, and it will prompt for the owner password before a user can change the restrictions.

Apple Preview on macOS opens permission-restricted files and will generally honour the print and copy flags for its own commands. Its handling of more specialized flags, including the accessibility bit and the high-quality print bit, is less predictable, and you should test any sensitive workflow on a current macOS release.

Browser PDF viewers, including the built-in viewers in Chromium-based and Firefox browsers, render PDFs with their own engines. Their handling of permissions varies. Some block printing and text selection for restricted files, while others ignore some flags. Do not assume that a browser viewer will behave like Acrobat.

LibreOffice opens PDF files primarily through its Draw component, and it does not treat PDF permissions as a rule for its import process in the way Acrobat does. Whether restrictions are respected in the way you intend depends on the import path and version, so do not rely on LibreOffice to enforce restrictions on your documents.

Across all these readers, the consistent observation is that enforcement is a feature of the reader, not of the file. The same file can be restricted in one application and unrestricted in another. That is the basic reason permission flags cannot be treated as a security control on their own.

How owner-password restrictions are bypassed

We describe bypass techniques here because understanding them is necessary for making sound decisions, not to encourage misuse. Several well-known, widely used tools can remove owner-password restrictions from a file that the reader can already open.

The most direct is qpdf, an open-source command-line tool. When the file can be opened without a user password, qpdf can write a copy without encryption:

qpdf --decrypt input.pdf unrestricted.pdf

If the file requires a user password and you hold it, add the password option, and the result is an unencrypted copy with no permission restrictions. The same operation is available in libraries such as pikepdf, which exposes the decrypted document for programmatic use. Ghostscript's PDF writing device can also re-render a document into a new file, and that output does not carry the original restrictions.

These tools are not exotic. They are standard in document-processing pipelines, and that is precisely why owner-password restrictions should never be treated as a secure boundary. If a file is readable, a tool that writes a new copy will usually remove the restrictions along with the encryption wrapper.

The bypass path that matters most in practice is simpler still. A recipient who can see the document can photograph the screen, take screenshots, or use an operating system's built-in print-to-PDF function, which produces a new file with the visible content. Permissions are a feature of the original file, and a new file is not bound by them.

What permissions are good for

Permissions are not useless. They are valuable in several ways, provided you understand their scope.

They signal intent to compliant software and to the people using it. A document marked as not to be printed, and opened in a viewer that enforces the restriction, will behave as the sender intended. For many internal and commercial contexts, that is enough to set a norm.

They reduce accidental copying and editing. A form that is locked against editing except in the fields that need completion protects against a well-meaning colleague altering the wording of a contract, even if the same colleague could bypass the protection with effort.

They support workflow controls. A document that allows form filling but not assembly can be routed through an approval process where the structure remains fixed. Permission flags are a simple way to express that the document is a form to be completed rather than a text to be rewritten.

They help with accessibility policy. By keeping the accessibility extraction bit set while restricting general copy, the sender preserves the document's usability for assistive technology while still expressing a preference about general copying.

They complement, rather than replace, confidentiality controls. When a file is protected with a user password and also carries permissions, the permissions express a usage policy for those who legitimately hold the password.

Setting and checking permissions

In Acrobat Pro, you can set permissions under File, then Properties, then Security, or through the Protect Using Password workflow, which we described in our password protection tutorial. Acrobat asks for the permissions password, which is the owner password, and then lets you choose which operations to allow.

To check the flags of an existing file from the command line, use qpdf:

qpdf --show-encryption input.pdf

The output lists the permission values for printing, modifying, extracting, annotating and so on. The exact labels vary between qpdf versions, but the information is the same. Use it to confirm that the settings you intended are the settings the file contains, rather than assuming them from the dialog.

To check whether a file is restricted at all, look for an encryption dictionary. If there is none, the file has no permission flags, and every operation is permitted by the format. If the file has an encryption dictionary but no user password, it is openable by anyone and its restrictions are advisory.

Practical guidance for legal, IT and admin teams

For teams that handle contracts, personal data and regulated records, the following points are worth turning into written procedure.

Decide, for each document class, whether the requirement is confidentiality, usage control, or both. Confidentiality requires controlling who can open the file. Usage control requires permissions, and it binds only compliant software.

Do not describe a permission-restricted PDF as "secure" or "locked" in external communications. The accurate description is that the sender has asked compliant viewers to restrict certain actions. Overstating the protection creates a legal and reputational risk if the document is later copied.

Where confidentiality matters, combine a strong, unique user password with a controlled sharing channel, and consider a server-side system that can revoke access and log views. The comparison in our secure sharing link article explains why these two approaches solve different problems.

Where a document must remain in a specific form, such as a signed agreement, prefer a digital signature over a permission flag. A signature protects integrity and attribution, which is a different property from confidentiality or usage control. See our guide on verifying a digitally signed PDF for how to check those signatures.

Test the restriction in the viewers your recipients actually use, and in a clean environment, before you rely on it. Record the result in your procedure, so the next person who sends a restricted document knows what to expect.

Finally, remember that the most effective protection for a sensitive document is often not to send it in full. If the recipient needs a summary, a redacted version or a specific extract, produce that and keep the complete document within your control.