It runs on your PC, not ours. A separate cloud product is planned

Opening and saving

The Two Passwords in a PDF, and Which One You Are Asked For

Two passwords can sit in a PDF and only one of them decides whether it opens. The other decides what a reader is asked to permit once it has, which is a weaker thing than it sounds. Creasepoint asks for the first when the engine refuses the file without it, and never asks for the second.

Support articleUpdated

Checked against the current Windows build. Where an article names a menu, a button or a message, that is the wording in the application, not a paraphrase.

Only one of the two decides whether the file opens

The user password is the one that opens the document. Without it there is nothing to decrypt with, and no way round that. The owner password governs permissions — printing, copying text, editing — and a document can carry it while the user password is empty, in which case the file opens for everybody and merely asks readers to behave.

That second arrangement is ordinary in Indian paperwork: government forms, bank statements and publisher files often restrict what you may do rather than whether you may look. Creasepoint opens those without a prompt, as it should. Permissions are advice to other software and not a lock, which the Protect panel says on screen rather than leaving you to infer. The password is the lock. The permission bits are a request.

What the prompt does with your answer

Before anything else touches a document, its bytes are searched for /Encrypt. That search deliberately over-reports, so a second step asks the reader whether it genuinely refuses the file without a password. Only then does the prompt appear, headed “This document is protected.” and, on a wrong answer, “That password did not open it.”

The password is used once, to produce a decrypted copy in memory. Nothing is written to disk, nothing is remembered between sessions, and the password reaches no log, because this application does not keep one. For as long as the document stays open, a banner above the pages says what you are working with: a copy in memory without the encryption, a file on disk that still has its password, and a save from here that will be a new file without one.

Removing a password writes a new file, and has to

Once you have typed the password, the copy in front of you already carries no encryption. So the Remove password tool in the Secure tab has nothing left to strip: its button reads “Save a copy without the password”, and what it does is ask where to put the copy you already have. The protected file is not touched and keeps its password.

On the command line the same job is creasepoint unlock report.pdf --password <pw> --out plain.pdf. Give --password with no value after it and it is asked for without echoing, which keeps it out of your shell history and out of the process list. None of this is recovery. Without the correct password there is nothing here that opens the file, no attack on it, and no plan to add one.

The boxes in the Protect panel, and what they promise

Protect asks for a password to open, the same one again to confirm, and an optional owner password. Beneath those, three tick-boxes headed “ASK READERS TO ALLOW” cover printing, copying text and editing. The encryption is AES-256, the strongest the PDF format defines, and the result is reopened and checked before it is written out.

The owner password deserves a decision rather than a blank. Leave it empty and a random one is generated and discarded, which fixes the permissions you chose: nobody, including you, can change them later without removing the password and protecting the file again. A password may be at most 127 bytes of UTF-8, because a longer one would be silently truncated and would then not be the password you typed. A document that is already protected is refused rather than re-encrypted, and the message tells you to remove the existing password first.

A password controls who opens the file and nothing else

Everything inside a protected document is still inside it. Metadata, attachments and anything you cropped out of view survive encryption exactly as they survive an ordinary save, and whoever has the password has all of it. A highlight is an annotation drawn over the words. A black rectangle is a rectangle, and the account number underneath it is still there and still searchable. Creasepoint ships no redaction tool, which is written down on the limitations page rather than left for you to find out.

The other thing a password does not do is travel. Encrypting the copy on your desk changes nothing about the version you emailed last week or the one on a pen drive in a drawer. Check that the file you are about to attach is the protected one, and not the original sitting beside it under a similar name.

IF THIS DID NOT HELP

The two places worth looking next.

Read the matching guide if you want the reasoning rather than the fix, and check limitations before spending any longer on it — some of what people look for here is absent on purpose.