What are PDF permissions?

Permissions live in the encryption dictionary as a single integer whose individual bits each correspond to one operation. They exist only alongside encryption — an unencrypted PDF has nowhere to record them — which is why applying restrictions always involves encrypting the file, usually with an owner password and often with no user password at all.

The operations the specification defines are specific. Printing the document. Modifying its contents. Copying or otherwise extracting text and graphics. Adding or modifying annotations. Filling in form fields, which can be permitted even when general modification is not. Extracting content for accessibility purposes, so that assistive technology is not blocked by a copy restriction. Assembling the document — inserting, rotating and deleting pages, or adding bookmarks — again separable from full modification. And printing at high resolution, which can be denied while low-resolution printing remains allowed, an arrangement intended to let someone print a usable reference copy without producing a press-quality reproduction.

The granularity is genuinely thoughtful. Allowing form filling but not content editing, or accessibility extraction but not general copying, expresses distinctions that matter. What it does not do is create any mechanism to make those distinctions hold.

This is the point that everything else follows from: a permission bit is a statement recorded in a file, and honouring it is a decision made by software. When you open a restricted PDF and find the copy command greyed out, that greying is your viewer choosing to grey it. Nothing in the file prevented the action. The viewer read a flag and elected to comply.

A different viewer may read the same flag and do nothing about it. Not through malice or by defeating anything — there is nothing to defeat. The content is already decrypted in front of it, because a file with an empty user password hands every reader the key. Enabling a menu item at that point requires no cryptography, no cracking and no cleverness; it requires only that the program not implement the restriction. Library code that manipulates PDFs programmatically frequently ignores permissions entirely, because from a library author viewpoint they are advisory metadata about intent.

And even a fully compliant viewer cannot close the obvious routes. If the page can be displayed, it can be screenshotted. If it can be printed, it can be printed to a fresh PDF with no flags set. If it can be read, it can be retyped. Restricting copy-and-paste raises effort; it does not withhold content from anyone who can see the page.

One consequence deserves flagging because it causes real harm: a copy restriction can interfere with assistive technology. The specification provides a separate accessibility-extraction bit precisely so that screen readers remain able to read a document whose text is otherwise restricted, but tooling that clears permissions broadly can deny it. Restricting copying on a document people may need read aloud carries a cost that falls on the wrong people while providing almost no protection against anyone determined.

Hold the two mechanisms apart. Encryption with a user password changes the bytes: without the password there is no readable content, and the protection does not depend on the good manners of whatever software opens the file. Permissions leave the content fully readable and ask nicely that certain actions not be offered. One is a locked door; the other is a sign on an open one.

So the decision is about what you actually need. If the content must not reach people who lack a credential, encrypt it with a user password and get that password to the right people by some other channel. That is the only PDF mechanism that genuinely withholds content. If you instead want to communicate how a document should be used — that it is a reference copy not intended for reprinting, or a form to be filled rather than edited — permissions state that intent clearly within the document, and cooperative software will reflect it in its interface.

What is not defensible is treating the second as though it were the first. A PDF restricted only by permission flags should never be described as protected, because a recipient with ordinary tools will experience no restriction whatsoever and will not have done anything unusual to get there. If a file matters, check what it actually carries: whether it is encrypted, with which algorithm, and whether a user password is required at all. The answer to that last question is what determines whether the document is protected or merely annotated with wishes.