Protect troubleshooting: already-encrypted files, invalid PDFs, and permissions that don't stick

Common problems when password-protecting a PDF at /app/protect, with causes and fixes. Everything in this tool runs locally in your browser — the PDF and the password are never uploaded.

"This PDF is already password-protected"

Protect shows this banner when the file you dropped is already encrypted. The encryption engine can't open an encrypted PDF to re-encrypt it, and stacking a second password on top isn't possible anyway.

1. Open Unlock and load the same file.
2. Enter its current password and download the unlocked copy.
3. Return to Protect and protect the unlocked copy with your new password and permissions.

"This file isn't a valid PDF (truncated, corrupted, or wrong file type)"

The pre-flight check couldn't parse the file. This usually means a download was cut short, the file is damaged, or it isn't really a PDF — for example, a Word document renamed to .pdf.

1. Re-export or re-download the file from its original source.
2. Confirm it opens in a normal PDF viewer before retrying.
3. If it only exists in another format, convert it to a real PDF first, then protect the result.

The file won't drop — "AttachKit caps drops at 100 MB"

To keep your browser responsive, the drop zone rejects files over 100 MB.

1. Compress the PDF to shrink heavy scans below the cap, or
2. Split it into parts with Pages and run each part through Protect separately.

The "Protect + download" button is greyed out

The open password is required — the button stays disabled until you've typed something into Password to open the PDF. There's no minimum length, but pick something you can store safely: the password is never sent to or stored by AttachKit, so it can't be recovered later.

Recipients can still copy or print despite unchecked permissions

This is a limitation of how PDF permissions work, not a fault in your file. Unchecked permissions are written into the PDF as restriction flags. Adobe Acrobat and most desktop readers honour them; many web-based viewers ignore them entirely. And anyone with the open password can read the document.

1. Treat permissions as a request, not a hard lock.
2. If specific content must never be seen or extracted, redact it before protecting — redaction removes the content from the file, while permissions only ask viewers not to expose it.

Also note that text extraction for accessibility is deliberately always allowed, so screen readers keep working even when "Copying text" is unchecked.

"Couldn't protect the PDF."

This is the message Protect shows whenever encryption fails; the precise cause is logged automatically so support can look it up. The two usual culprits:

• The engine couldn't load. The encryption engine is a WebAssembly build of qpdf served from AttachKit's own domain, fetched the first time you click Protect + download. Check your connection, allow this site in any ad blocker or script-blocking extension, then reload and retry.
• The engine ran but couldn't produce a valid encrypted file. Most often the file is actually already password-protected — run it through Unlock first. Otherwise the file may be damaged in a way the pre-flight check missed; re-export it from its original source and try again.

If the message says "AttachKit was just updated" instead, the tab is on an old version of the app — refresh the page once and retry.

If it still fails, the underlying error has already been logged automatically — include which tool produced the PDF when you contact support below.

I forgot the password I set

AttachKit can't help here, by design: the password never left your browser, nothing was stored, and AES-256 encryption has no backdoor — there is no recovery. Go back to your original, unprotected copy (Protect never modifies it; it downloads a new -protected.pdf file) and protect that again with a password you've saved somewhere safe.

Still stuck?

Contact support — include the exact error message and where the PDF came from, and we'll dig in.