NetroDoc test notes

Protect and Unlock PDF: What Our AES-256 Password Test Verified

Password protection is only useful if the output really requires the password and the reverse operation actually removes that protection. We tested both directions with a controlled PDF and inspected the result with PyMuPDF instead of relying on the viewer prompt alone.

Controlled evidence · 2026-09-09

What the measured run showed

These figures describe the controlled fixture documented for this guide. They are evidence for the tested case, not a universal performance guarantee.

Encryption implementationPyMuPDF AES-256
Source pages1 in evidence fixture
Empty passwordRejected after protect
Correct passwordAccepted
Wrong unlock passwordRejected
Unlocked outputNo password required

What the Protect PDF test verified

The test started with a one-page PDF containing a known text marker. NetroDoc protected it through the same converter used by the live tool, then reopened the result with PyMuPDF and checked whether the file reported that a password was required.

The implementation saves with PyMuPDF's PDF_ENCRYPT_AES_256 mode, a random owner password generated by the service, and the user-supplied password as the user password. After saving, the converter verifies the protection before returning the file.

  • The protected output reported that a password was required.
  • Authentication with an empty password failed.
  • Authentication with the requested password succeeded.
  • The page count matched the source.
  • The known text marker remained present in the protected/unlocked lifecycle test.

What the Unlock PDF test verified

We then passed the protected fixture through Unlock PDF. A deliberately wrong password was rejected before the output was created. The correct password was accepted and the resulting PDF reopened without requiring a password.

The unlock implementation saves the authenticated document with PDF_ENCRYPT_NONE and then reopens the output to verify that password protection is gone and that the page count still matches the source.

  • A wrong password did not unlock the test file.
  • The correct password produced an unprotected PDF.
  • The unlocked output did not report needs_pass.
  • The page count was retained.

Encryption is not the same as access control after sharing

PDF password encryption protects the file while the recipient does not know the password. Once somebody legitimately has the password and can open the document, they may be able to save, capture, print, or otherwise reproduce its contents depending on their software and permissions.

For that reason, Protect PDF should not be described as DRM or as a guarantee that an authorized reader cannot copy information. It is a password-based encryption layer around the PDF file.

Password choice still matters

AES-256 describes the encryption method used by the implementation, but a weak or reused password can still undermine practical security. A short common password is easier to guess than a long unique passphrase even when the encryption algorithm itself is strong.

NetroDoc currently accepts passwords up to 40 characters for Protect PDF. Use a password that is unique to the document context, and share it through a different channel when the document is sensitive.

  • Avoid names, dates, and common words as the whole password.
  • Prefer a longer unique password or passphrase.
  • Do not send the protected file and its password in the same message when separation matters.
  • Keep an original copy if losing the password would create a serious problem.

Current limits and viewer differences

The tested configuration allows Protect PDF and Unlock PDF jobs up to 2,000 pages. That is a service limit, not a claim that every 2,000-page PDF will process equally quickly or contain only standard structures.

PDF viewers can display password and permission behaviour differently. Our evidence checked the PDF encryption state directly with PyMuPDF; it did not benchmark every desktop, mobile, or browser PDF viewer.

Limits of this evidence

This evidence used a controlled one-page fixture and verified the password state, correct and incorrect authentication paths, page count, and retained text marker. It was not a cryptographic penetration test and qpdf was not available in the tested runtime for an independent command-line probe.

The accurate conclusion is that the NetroDoc implementation used AES-256 mode and the tested output required the chosen password; broader security claims would need a different test scope.

Temporary processing and privacy

Protect and Unlock run in temporary processing storage. The application-level evidence wave verified cleanup behaviour for temporary result paths; passwords are used to perform the requested operation and are not presented in these guides as a permanent account credential.

Read the Privacy Policy →

Troubleshooting

The protected PDF still opens on my device

Check whether the viewer already cached the password or whether you are opening the original file instead of the protected output. Reopen the downloaded result in a fresh viewer session.

Unlock says the password is wrong

The tested implementation rejects authentication when the supplied password does not open the PDF. Confirm the exact password and keyboard layout.

I forgot the password

NetroDoc's Unlock tool requires a password that successfully authenticates the PDF. This guide does not claim password recovery or password cracking.

Tools used with this topic

Protect PDFOpen the NetroDoc tool → Unlock PDFOpen the NetroDoc tool → Merge PDFOpen the NetroDoc tool →

Method note

NetroDoc publishes measured claims only after a controlled run completes successfully. Untested cases are kept out of the conclusion. The evidence run for this publication wave used the same production runtime components while operating on an isolated candidate and temporary server paths.

Back to all Guides →