A password that locks a PDF is only as strong as its entropy, and a 16-character string drawn from uppercase letters, lowercase letters, digits and symbols reaches roughly 103 bits of randomness — the threshold where offline brute-force attacks stop being practical. To "create a password to PDF" really means doing two separate jobs, and getting both right is what keeps a document out of the wrong hands. The first job is the string itself: it has to be long, random and unreused, because whatever PDF encryption algorithm the tool uses (usually AES-128 or AES-256 in modern products) only protects the file until someone guesses the key. The second job is applying that string correctly inside a PDF tool, with separate passwords for opening and editing where the format supports it. This article focuses on the first half of that workflow — generating a strong, unrepeatable password you can paste into any PDF protection dialog. The actual application tool you choose does not change the requirement that the password be high-entropy in the first place, so the same generation step applies whether you use Adobe Acrobat, LibreOffice, Preview on macOS, Windows-built PDF features or a free web-based PDF locker.
What "Create a Password to PDF" Actually Means
Every PDF password prompt really asks the same question: what string will the reader have to type before the file unmasks itself? In the PDF world that string can serve two distinct roles depending on the tool you are using:
- An open password, sometimes called a user password, gates the file entirely. Without it, the PDF reader refuses to decrypt the content at all.
- A permissions password, sometimes called an owner password, lets anyone open and read the PDF but blocks editing, printing or copying until a second string is supplied.
Think of these as two locks on the same door. The open password protects confidentiality — keeping a contract, a tax return or a scan of an identity document away from a stranger who finds the file. The permissions password protects integrity — preventing someone from editing the document or extracting its text once it has been legitimately opened. A strong creation step matters for both, but it matters more for the open password, because that is the one an attacker has to actually defeat to see anything inside the document.
Why a Random PDF Password Beats a Memorable One
Human-chosen passwords cluster around predictable patterns, and PDFs are an unusually tempting target because the file format is widely supported, often shared over email, and frequently contains the exact kind of information attackers want — financial figures, legal agreements, scans of identity documents. Once a PDF is in someone else's hands, the only thing standing between the file and offline cracking is the entropy of the password that locks it. A modern workstation can test billions of guesses per second against a stolen PDF, which is why "Spring2024!" or a pet's name plus a birth year falls in seconds even though it looks complex on the surface.
A genuinely random string removes the patterns attackers bet on. There is no dictionary entry for a randomly drawn mix of mixed-case letters, digits and symbols, so brute force — and brute force scales with entropy, not with clever substitution — becomes the only viable approach. A generator backed by a cryptographically secure random number generator removes those patterns entirely by drawing characters uniformly so the output has no exploitable bias. The strongest signal in current guidance is to favor length over forced complexity and to keep every password unique so a breach on one document does not cascade into the next. Both of those defaults are built into how the Password Generator works.
Generate a PDF Password Step by Step
- Open the Password Generator in a browser tab. Because everything runs locally, no network request carries the password off your device, and closing the tab discards it.
- Drag the length slider (or type into the number box) up to at least 16. Sixteen characters is a strong default for any document that matters; longer is stronger because entropy scales with character count.
- Tick every character type you are willing to type: uppercase, lowercase, digits and symbols. Enabling all four gives a pool of 86 distinct characters, which is the widest practical set.
- If you might ever need to read the password back by hand — for example, dictating it over the phone — switch on the "exclude ambiguous characters" option so 0, O, 1 and l get filtered out of the output.
- Read the strength meter and the bits-of-entropy estimate that the tool reports. Aim for 100+ bits for a document that should stay private for years.
- Click Copy, then paste the password into the open-password (and optionally the permissions-password) field of your PDF encryption tool. If the dialog has a confirm field, paste again there. Click Generate new password at any point to roll a fresh string without changing your length or character settings.
Picking the Right Length and Character Mix
The single biggest lever you control is length. Doubling the number of characters roughly squares the work an attacker has to do, while swapping one character set for a bigger one only multiplies the work by a fixed factor. As a rough benchmark, with all four character sets enabled the pool contains 86 characters and each character adds about 6.4 bits of entropy. The strength meter reports Shannon entropy, computed as length × log2(pool size). Take a concrete example: a 16-character password with all four character sets enabled sits in a pool of 86 characters, so 16 × log2(86) = 16 × 6.426 = 102.8 bits, rounded to roughly 103 bits — exactly the figure the strength meter reports and the threshold that puts the string out of reach of offline brute force. The table below shows how common choices translate:
| Length | Pool size | Entropy (bits) | Strength band |
|---|---|---|---|
| 8 | 86 | ~51 | Weak — guesses in hours |
| 12 | 86 | ~77 | Fair — survives casual cracking |
| 16 | 86 | ~103 | Strong — recommended default |
| 20 | 86 | ~129 | Strong — long-lived secrets |
| 24 | 86 | ~154 | Strong — high-value documents |
The same length with a smaller pool gives less entropy. An eight-character password from lowercase letters only — 26 characters per slot — reaches just 37 bits, well below what an offline attack handles in moments. Excluding ambiguous characters trims the pool slightly, but it usually buys you a far more readable password, which is a worthwhile trade for a string you only type occasionally. The rule of thumb the strength meter uses is the same one OWASP's authentication cheat sheet tends to land on: under 60 bits is weak, 60 to 100 bits is fair, and 100+ bits is strong against offline brute force.
Apply the Generated String to Your PDF
The password you have just copied is a normal string, so any tool that accepts a PDF password can take it. Common places to paste it include:
- Adobe Acrobat's "Protect Using Password" dialog, which lets you choose between an open password and a permissions password separately.
- LibreOffice Draw or Writer's "Encrypt PDF" export option, available when saving or exporting any document as PDF.
- macOS Preview, which can apply an open password through File → Export → PDF → Show Details → Require Password To Open.
- Windows File Explorer's PDF encryption support, plus dedicated free utilities such as PDFsam, qpdf or pdftk that can encrypt PDFs from the command line.
Paste the password from the generator into both the password field and the confirm field, then save the file. Verify the lock by closing the document and reopening it before you share it anywhere. If the file opens without prompting but menus such as edit, print and copy are greyed out, you typed it into the permissions-only field; if the dialog prompts for a password before opening, you typed it into the open-password field.
What Often Goes Wrong with PDF Passwords
A strong generator does most of the work, but a few habits can undo the protection it provides:
- Reusing the same PDF password across multiple files. Once one PDF leaks, every other document locked with the same string falls to the same guess.
- Storing the password next to the PDF, or naming the file "contract.pdf.password.txt". Encryption protects the file only as long as the key lives somewhere the attacker cannot reach at the same time.
- Relying on a short password plus a $ sign and an exclamation mark. Modern crackers weight their dictionaries toward exactly that pattern.
- Sharing the password over the same channel as the PDF. Email plus email, even with TLS in transit, sends the key and the lock through the same interception surface.
- Trusting tools that encrypt the PDF on a remote server, where the uploaded password briefly exists outside your control. Local-only generation keeps that exposure to zero.
The simplest countermeasure is a password manager: let a vault hold the long random string, copy it into the PDF tool at encryption time, and let autofill paste it back at decryption time. Modern guidance from NIST (SP 800-63B) and the OWASP authentication cheat sheet makes the same point — unique long strings stored in a manager beat memorable passwords every time.
If you're weighing options, Check Password Strength in JavaScript Without a Server covers this in detail.