PDF passwords, permissions and signatures solve different problems

A password, a printing restriction and a digital signature are not interchangeable security controls. Choose the mechanism that matches your goal, then test the recipient’s actual experience with the saved file.

Start with the question you need to answer

Do you want to stop an unauthorised person opening a document? Do you want to discourage editing? Do you need a recipient to detect changes after signing? Or do you need to remove information before sharing? Each question points to a different operation. A single “secure PDF” button cannot make these distinctions disappear.

Encryption addresses access to protected contents. Permission settings express restrictions that cooperating readers may enforce. A certificate signature can support integrity checking and identification through a certificate trust model. Redaction removes selected information from a delivery copy. Combining them can be appropriate, but using one as a substitute for another creates false confidence.

Write down the intended recipient and the delivery requirement before processing. A portal may reject encrypted files because its own system needs to inspect them. A signed document may need to remain byte-for-byte intact. An anonymous public example may require redaction and sanitization rather than a password that every reader must receive.

Opening passwords protect access to encrypted contents

SandboxPDF’s Protect PDF uses AES-256 encryption for the supported password-protection workflow. Choose a strong, unique password and retain it securely. A powerful encryption algorithm does not compensate for a short, predictable password. Someone who obtains an encrypted file may be able to attempt guesses without interacting with your website.

Send the password through an appropriate separate channel when that fits your organisation’s procedure. Putting it in the same email as the attachment reduces the benefit if that message is exposed. Consider the recipient’s ability to store the password and reopen the file later. Security that makes the authorised workflow impractical often leads to unsafe workarounds.

Keep an unencrypted original in a suitably protected location if your records policy permits it. There is no SandboxPDF recovery service for a forgotten document password. The tool processes locally and does not retain a copy of either the original or the password that could be used to restore access.

Permissions depend on the software reading the file

PDF permission flags can request restrictions such as preventing printing or editing. They are not equivalent to removing the underlying information. A program that already has access to decrypted content may not honour every requested restriction in the same way. Do not treat a disabled toolbar button as proof that copying or modification is impossible.

If a recipient can see the page, they can at least reproduce its visible content through methods outside the PDF’s permission system. That practical fact matters when deciding whether to share information at all. Restrictions can be part of an expected workflow, but they do not replace contractual, organisational or access-control measures where those are needed.

For technical background, qpdf distinguishes encryption from permission enforcement in its encryption documentation. The useful lesson is to identify the threat you are addressing. Preventing an unauthorised opening and asking an authorised viewer not to print are different objectives.

Unlocking is an authorised transformation

Unlock PDF is for documents you own or have permission to modify, using the correct password. It is not a password-cracking service. Removing encryption creates a new copy that can be opened without the previous protection. Decide where that copy will be stored and who may receive it before exporting.

Verify that the unlocked result opens in a fresh reader session without asking for the password. Also check that page count, forms and visible content remain appropriate. If a file contains a digital signature, rewriting it may affect the signature’s validity. Preserve the signed original and follow the recipient’s requirements rather than assuming unlocking is a harmless administrative change.

Avoid leaving an unprotected derivative in a shared download folder. The convenience of removing a password can change the document’s exposure long after the immediate task is finished. Use clear filenames so that you do not accidentally distribute the unlocked copy when the encrypted version was intended.

A signature answers a different question

A visual signature is a name or handwritten mark placed on a page. It changes appearance but does not itself provide cryptographic integrity checking. A certificate-based signature uses a private key and certificate to sign document bytes. A capable reader can then assess whether the signed content has changed and whether the certificate is trusted under its validation settings.

Trust is not automatic. A signature can be cryptographically intact while the signer’s certificate is unknown to the recipient. A self-signed certificate may therefore display a warning even though the file has not changed. Conversely, a familiar-looking name printed on the page is not evidence that a valid certificate signature exists.

SandboxPDF offers separate visual signing and certificate signing tools. The certificate feature does not establish issuer trust, check revocation or add a trusted timestamp. It is not a remote signing service. Check the exact signing procedure required for your transaction instead of assuming a general PDF feature supplies a particular legal status.

Redaction removes information instead of controlling access

If a recipient should never receive an account number, encrypting the complete document and giving them the password does not meet that requirement. Once opened, the number is available. Use an appropriate redaction workflow to create a copy that no longer contains the information you intend to withhold, then verify that copy.

Similarly, cropping or painting over text is not sufficient unless the export actually removes the source data. SandboxPDF’s redaction tool rebuilds pages as images after covering selected areas, discarding the original text and object structures. This trades searchability and interactive features for a simpler delivery representation.

Redaction is a content decision as well as a technical operation. A repeated identifier may appear in several locations or be encoded in a barcode. The tool cannot decide every disclosure requirement for you. See the redaction guide for the review steps and the limitations of visual coverage.

Plan the order of operations

Prepare content first: organise pages, correct orientation, complete required fields and apply any redactions or cleanup. Review the resulting document. Sign only after the intended content is final. Subsequent editing, sanitization or conversion can change the bytes and invalidate or alter the meaning of a signature validation result.

Encryption and signing combinations can have compatibility implications. If the receiving system has a prescribed order or format, follow that requirement. A workflow that opens correctly in your browser may behave differently in a document management system or a desktop reader. Test with the recipient’s expected software where possible.

Keep distinct originals and derivatives. A signed source, a redacted public copy and an encrypted delivery package are not necessarily the same record. A clear naming convention and a brief record of transformations help prevent mistakes when several similar files exist.

Example: sending a private invoice

Suppose an invoice contains payment information that the customer needs. Redacting the payment details would make it less useful. Encrypting a delivery copy may be appropriate if the agreed channel calls for it. Choose a strong password, confirm the customer can use an encrypted PDF and share the password through the agreed separate method.

Now suppose you want to publish that invoice as a design sample. The audience does not need the customer’s name, reference or account details. A password is unsuitable because the public would need it anyway. Create a redacted and sanitized sample, review every page and remove identifying information from the filename as well.

Finally, suppose the customer requires a certificate-signed invoice. That is a third requirement. Use the expected certificate and validation procedure, and avoid modifying the signed output afterwards. The same source document can lead to three different deliverables because the purposes differ.

Verify security behaviour, not just appearance

For encryption, close the original session and reopen the exported file. Confirm that the correct password works and an incorrect password is rejected. For a signature, inspect the reader’s signature panel and distinguish content integrity from certificate trust and timestamp status. For redaction, review the marked areas and inspect the saved file for original text, comments and attachments.

Do not rely on a thumbnail or a success banner as the only check. Those signals show that some processing completed; they do not establish that the file meets every access, identity or disclosure requirement. Test the exact exported bytes that will be sent, using a fresh reader session where practical.

Document security is strongest when the mechanism, the workflow and the acceptance check all match the intended purpose. A password is useful for one problem, a signature for another and redaction for a third. Keeping those distinctions clear avoids both unnecessary complexity and dangerous assumptions.

Keep the access procedure separate from the document itself. Sending the password in the same message as the encrypted attachment can weaken the protection you intended. Use an appropriate sharing method agreed with the recipient and verify that they can open the correct version.