Protect PDF
Add AES-256 password encryption to a PDF entirely in your browser.
How to protect a PDF
- 1
Choose your PDF
Select or drag and drop your PDF file.
- 2
Set a password
Enter and confirm the password for the PDF.
- 3
Download
Download your PDF.
An opening password protects access to the PDF, not every action after it opens
Protect PDF is for documents that should not open unless the recipient knows a password. SnakTool encrypts one unencrypted PDF with AES-256 and requires the password before a compatible reader can open the protected copy. That is different from simply hiding a file behind a website login or renaming it: the PDF itself is encrypted.
This kind of protection is useful when a report, contract draft, statement, application or other private document still needs to travel as a normal PDF but should not be readable by someone who obtains the file without the password. The protection travels with the downloaded PDF rather than depending on continued access to SnakTool.
Once an authorized recipient opens the document, an opening password does not make the visible information impossible to copy, photograph or capture. Password encryption controls access to the file; it is not digital rights management and it cannot revoke a copy that has already been delivered.
Document-open passwords and permissions passwords solve different problems
PDF software commonly distinguishes a document-open password from a permissions or owner password. The first controls whether the document can be opened. Permission settings can instead ask a conforming reader to restrict actions such as printing, copying or editing after the PDF is open.
SnakTool's Protect PDF interface exposes one opening password and its confirmation. It does not offer checkboxes for printing, copying, commenting or editing permissions, so do not use this tool expecting to configure those recipient actions. The engine creates a separate random owner password internally as part of the encryption operation, but that value is not presented as a permissions-management feature.
Permission restrictions also should not be confused with encryption strength. PDF security software ultimately decides how permission flags are enforced, while a nonempty opening password is needed to recover access to the encrypted document. For SnakTool, the user-facing security decision is deliberately narrower: choose the password required to open the protected output.
AES-256 is only as useful as the password protecting access
The current implementation requests 256-bit PDF encryption. Modern PDF security guidance favors AES-based encryption over obsolete 40-bit and older RC4-based modes, but the algorithm does not turn a weak password into a strong secret. An easily guessed password can remain the practical weak point.
Prefer a long, unique password or passphrase that is not reused for another document or account. Length is generally more valuable than predictable substitutions such as replacing one letter with a symbol. A password manager can generate and retain a random value when memorability is not important.
SnakTool accepts a nonempty password up to 127 UTF-8 bytes and rejects a NUL character. That is a byte limit, not a 127-character promise: many non-ASCII characters occupy more than one UTF-8 byte. The confirmation must match exactly before encryption begins.
The password and the protected PDF should not travel together
If the password is written in the same message that carries the protected file, anyone who gains access to that message may receive both parts needed to open it. When the document is sensitive, send the password through a separate appropriate channel and confirm the recipient before disclosing it.
Keep your own secure record as well. SnakTool does not provide password recovery, and the password is needed later if you want to open the protected copy or use Unlock PDF to remove supported encryption. Losing the only known password can make the protected document unusable to you.
Password protection also does not replace decisions about where copies are stored. Backups, email attachments, downloaded originals and previously shared unencrypted copies remain separate exposure points even after you create a protected version.
Protection is not redaction, a digital signature or proof of authorship
Encrypting a PDF does not remove sensitive information from its pages. If a recipient is allowed to open a page, the page content is still there. When information must be permanently removed before disclosure, use a genuine redaction workflow on the source document rather than placing a password around material the recipient should never receive.
Encryption also does not authenticate the author or prove that a document has not been altered in the way a cryptographic digital-signature workflow is intended to do. A password answers an access question: who knows the secret needed to open this copy? It does not establish who signed or issued the document.
These distinctions matter for contracts, records and regulated workflows. Protect PDF adds opening encryption; it does not claim legal-signature functionality, certificate security, recipient identity verification or compliance with a particular organization's document-handling policy.
Already-encrypted PDFs need a different first step
Protect PDF expects an unencrypted input. If the source is already encrypted, the engine rejects it rather than stacking another password layer on top. When you are authorized to change that document and know its current password, remove the supported encryption first and then protect the resulting PDF with the new password.
That sequence is different from changing a password inside a full PDF security editor. SnakTool currently separates the operations: Unlock PDF removes supported password encryption when you supply the known password, while Protect PDF encrypts an unencrypted PDF with a new opening password.
A PDF can also contain signatures, certificates, forms or other document-level features whose meaning extends beyond whether the file opens. Adding encryption rewrites the file, so do not assume an existing signed or certified workflow remains valid merely because the pages still look the same. Verify such documents with the software and policy used by the recipient.
SnakTool verifies the security change before publishing the download
Before encryption, the engine validates the PDF container, confirms that the source is not already encrypted and checks that the document has pages. It then creates a cryptographically random owner password internally and applies the opening password you entered with a 256-bit encryption request.
Afterward, SnakTool checks that the result reports itself as encrypted and reopens the result with your password to verify that its page count matches the source. It also checks the output against configured resource limits before returning the protected file. These checks are useful processing invariants, not a promise that every PDF feature or every reader has been exhaustively tested.
The downloaded filename keeps the source name with a protected suffix. Keep the original until you have independently tested the new copy; successful internal verification should not be your only check for an important document.
Test the protected copy as the recipient will receive it
Open the downloaded PDF in the reader the recipient is expected to use and confirm that it asks for the password. If your viewer has already cached credentials, close the document or test in a fresh session so a remembered password does not make the file appear unprotected.
After entering the password, inspect representative pages and any document behavior that matters to your workflow. AES-256 support is common in modern PDF software, but compatibility can vary across older or specialized readers. SnakTool does not provide a weaker-encryption compatibility selector.
Do this verification before deleting the unencrypted original or sending the only copy. A sensible protection workflow tests both sides of the boundary: the file should refuse unauthenticated opening, and it should remain usable for the authorized recipient after the correct password is supplied.
Local encryption changes the data path, not the security responsibilities
SnakTool performs this protection workflow in your browser using WebAssembly rather than sending the PDF to a conversion backend. That can matter for a sensitive source document because the file does not need to be uploaded to SnakTool for the encryption operation.
Local processing also means your device carries the workload. The tool has configurable limits for file size, PDF pages, output size, memory estimates and processing time, with tighter ceilings on lower-memory devices. A large or unusually complex PDF can therefore fail even when its contents are otherwise valid.
Browser-local processing is only one part of the document's security lifecycle. The strength and handling of the password, unencrypted copies left on the device, the channel used to share the password, the recipient's reader and what happens after the recipient opens the file all remain separate decisions.
What this tool supports
- Validates the source file before processing
- Preserves document page order and usability
- Creates a downloadable result in your browser
Limitations
- Unlocking requires the correct existing password
- Unsupported security handlers are rejected
- Rewriting invalidates existing digital signatures
Frequently asked questions about Protect PDF
How do I password-protect a PDF?
Choose one unencrypted PDF, enter and confirm a nonempty password, and run Protect PDF. SnakTool encrypts the document and saves a new protected copy whose filename ends in -protected.pdf.
What encryption does Protect PDF use?
The current engine requests 256-bit PDF encryption and creates an opening password that must be supplied to access the protected document in a compatible reader.
Can I prevent printing, copying or editing with Protect PDF?
Not with the current SnakTool interface. It does not expose permission checkboxes for printing, copying, editing, commenting or form filling. The feature is designed to require a password to open the PDF.
Can someone edit or copy the PDF after entering the opening password?
The opening password controls access, not everything an authorized reader can do after the document is open. Do not treat this tool as digital-rights management or as a guarantee that an authorized recipient cannot copy, capture or modify accessible content.
How strong should my PDF password be?
Use a long, unique password or passphrase that is difficult to guess and is not reused elsewhere. The current SnakTool input accepts 1 to 127 UTF-8 bytes and rejects a NUL character; the limit is measured in encoded bytes, so it is not always the same as 127 characters.
What happens if I forget the PDF password?
SnakTool does not store or recover the opening password for you. Keep it in a secure password manager or another appropriate record, because later opening or unlocking the protected copy depends on knowing an accepted password.
Does password-protecting a PDF hide or redact sensitive information?
No. Encryption controls access to the document; it does not remove information from pages. If a recipient should never receive particular text or images, use a proper redaction workflow before protecting the PDF.
Is password protection the same as digitally signing a PDF?
No. Encryption controls who can open the file when they know the password. A cryptographic digital signature is used for document integrity and signer authentication. Protect PDF does not add a digital signature or certificate.
Can I protect a PDF that is already password-protected?
No. The engine checks whether the input is encrypted and rejects an already-encrypted PDF. If you are authorized and know an accepted password, remove the supported encryption first and then protect the resulting accessible PDF with the new password.
Does adding a password change the PDF pages or image quality?
Protect PDF is a security operation rather than an image-conversion or downsampling tool. SnakTool verifies that the encrypted output has the same page count as the source, but important complex document features should still be tested in the intended PDF reader.
Will password protection make the PDF file larger?
Encryption can change the file's byte size because a new encrypted PDF is written, so the protected copy does not have to match the original size exactly. Protect PDF is not a compression tool and does not target a particular output size.
Will every PDF reader open an AES-256 protected PDF?
Modern PDF software commonly supports strong PDF encryption, but compatibility can vary across older or specialized readers. Test the downloaded protected copy in the reader the recipient is expected to use before relying on it.
Why does my protected PDF open without asking for a password?
First make sure you are testing the newly downloaded -protected.pdf file rather than the original. A PDF reader may also cache a password or keep an authenticated document session open, so close the file or test the protected copy in a fresh reader session.
How many pages can I password-protect at once?
Protect PDF accepts one document. The normal security policy allows up to 500 pages, a 192 MiB estimated-memory budget, a 32 MiB output ceiling and 90 seconds of processing; known low-memory devices use tighter limits of 250 pages, 128 MiB, 16 MiB output and 60 seconds.
Why can Protect PDF fail?
Protection can fail when the source is already encrypted, malformed, has no pages, exceeds the configured page, memory, output-size or time limits, uses a security-related structure the engine cannot process safely, or when the browser cannot provide the cryptographic randomness or WebAssembly support required by the local workflow.
Understand PDF passwords and encryption