Set PDF permissions

Provide a PDF reference and any combination of print, copy, edit, and annotate. The result uses lowercase canonical names, removes duplicates, and follows a stable order. If the list contains an unsupported name, the request fails clearly instead of passing an ambiguous policy to the next step in your document workflow. This keeps automated configurations consistent and reviewable.

Define the policy before changing the document

PDF security workflows often begin with a small configuration object long before an encryption library or document service touches the file. That configuration deserves the same validation as the document itself. A misspelled flag such as “printing” may otherwise be ignored, interpreted differently by separate libraries, or stored as if it were valid. This capability provides a narrow contract for that boundary. Send the PDF reference together with the permission names you intend to allow. The validator confirms that the PDF reference is present and that permissions is an array containing only print, copy, edit, and annotate. It then returns the accepted names in canonical order. It does not download, inspect, encrypt, or rewrite the PDF. Keeping validation separate makes the result useful as a safe input to a later protection step, a policy database, an approval screen, or an audit record. It also lets an application reject a bad selection immediately, before starting a slower or more expensive document operation.

How normalization produces a stable result

Permission lists frequently arrive from checkboxes, command-line arguments, imported settings, or several combined rules. Those sources can produce mixed capitalization, surrounding spaces, repeated values, and inconsistent ordering. The normalizer trims each string and converts it to lowercase before checking it against the supported vocabulary. Duplicate flags collapse into one entry because permissions represent a set rather than a sequence of commands. The output order is always print, copy, edit, then annotate, regardless of the order in which valid values were supplied. An empty array is valid and represents a policy that grants none of these four permissions. Any non-string value or unknown name makes the whole request fail with an invalid-input error; the tool never silently drops an unsupported flag. This all-or-nothing behavior is important for security-related settings because a partially accepted policy can misrepresent what the caller requested. The deterministic output is also straightforward to compare, cache, sign, review, and test across environments.

Use the normalized set in a complete PDF workflow

The returned array is a validated policy description, not a modified document. Pass it to the component that actually applies PDF encryption or owner-level restrictions, and consult that component’s documentation for the exact behavior of readers and operating systems. PDF permissions are generally advisory controls enforced by compliant software; they are not a substitute for access control, careful distribution, or encryption with an appropriate password. Separating policy validation from enforcement still has practical benefits. A web form can show a clean summary before submission, an API can store one consistent representation instead of many equivalent arrays, and a batch job can stop on the first unknown flag rather than producing files with uncertain settings. Because this capability uses no network service and does not decode the supplied PDF, it can run in the browser with the same deterministic result as the API. Browser use is free, while automated API requests use the published $0.002 base price. No document content is returned or retained by this validator.