PDF digital signatures, encryption and why file tools treat them differently
Digital signatures and encryption are trust and access-control mechanisms, not ordinary visual page features. Rewriting a signed document can invalidate the signature, while processing encrypted objects without the correct authorization and decryption rules is unsafe. Focused tools should therefore define these cases explicitly.
Last technical review: 2026-09-19
Key takeaways
- A digital signature covers a specific byte representation and revision state.
- Combining, compressing or rebuilding a signed PDF can invalidate or change the meaning of that signature.
- Encrypted PDFs require supported decryption behavior and authorization before content can be transformed safely.
- Rejecting trust-sensitive inputs can be the correct behavior for a focused transformation tool.
Why signatures are not just visible marks
A visible signature appearance on a page is only part of the story. Cryptographic PDF signatures are tied to document bytes and revisions. Changing those bytes can make the signature validation fail even when the visible signature image still appears.
A tool should never imply that trust remains intact merely because the visual mark survived a transformation.
Why merging signed PDFs is especially difficult
A merged document is a new document with a new structure. Original signatures normally do not become signatures over the combined result simply because their page appearances were copied.
Preserving legal or organizational signature semantics requires a dedicated signature-aware workflow, not a generic page merge.
Encryption needs explicit support
Encrypted PDFs can restrict access or protect object contents. A transformation engine needs the correct credentials and a defined decryption model before it can safely inspect and modify protected content.
Silently bypassing or partially processing an encrypted file would undermine both correctness and trust. A bounded tool can therefore decline encrypted inputs until that capability is implemented explicitly.
ZAMAZY policy for trust-sensitive PDFs
The current ZAMAZY PDF transformation tools decline encrypted or digitally signed inputs in the workflows where those trust properties cannot be safely preserved.
This is intentionally fail-closed behavior: the tool does not convert an unsupported trust state into a misleading successful result.
Example and decision guide
A drawn signature image and a cryptographic PDF signature can look similar but have different meaning. The image is page content; the digital signature binds a signing process to a document representation. A password prompt addresses access instead. Neither a visible stamp nor a file opening normally establishes that rewriting it is authorized or preserves its trust properties.
Preserve the signed original. Ask for an authorized unsigned source when a changed working copy is needed, or complete edits before signing the final document in an appropriate signing workflow. For encryption, use only access and decryption you are authorized to perform. ZAMAZY does not add decryption or signature-validation capability merely by recognizing a PDF header.
When this approach does not fit
Do not strip a signature, print a copy or remove a password and then describe the output as the same signed original. Some signing systems allow specifically defined later changes; a general merge or compression is not evidence of such permission. A separate file with unchanged-looking pages can still have a different verification or trust status.
Editorial illustration, not a benchmark. Addition reviewed on:
Sources and evidence boundaries
These sources explain formats and methods. They do not certify ZAMAZY; its supported facts and limits are stated on each tool page.
- Adobe: Permissions and limitations of signed PDFs — Signed-document editing restrictions; no legal-compliance assessment.
- PDF-LIB: PDFDocument API — Page-copy primitives; not a complete ZAMAZY preservation test.
Frequently asked questions
If a signature image is still visible, is the digital signature still valid?
Not necessarily. A cryptographic signature can be invalid even when its visible appearance remains on the page. Validation depends on the signed bytes and revision state.
Can two signed PDFs be merged while keeping both signatures valid?
A generic merge cannot safely make that promise. The combined file is a new document, so signature semantics require a specialized signature-aware process.
Why not just process an encrypted PDF after the browser can display it?
Displaying protected content and safely rewriting its encrypted object structure are different tasks. A transformation should support the relevant encryption and authorization model explicitly.