A 16-character password drawn from all four character types — uppercase, lowercase, digits, and symbols — carries roughly 103 bits of entropy, which is the threshold modern guidance treats as strong against offline brute-force attacks on a locked file. To make a password to a PDF means two distinct steps: producing a strong secret, and then applying that secret to encrypt the document. A random string from a cryptographically secure random number generator on your own device is the strongest possible first step, because humans consistently invent passwords that cluster around predictable patterns. A tool like the Password Generator produces a uniformly random string locally — using the browser's built-in crypto.getRandomValues as its entropy source — so the secret never leaves your tab. The second step is mechanical: paste the string into the password field of your PDF viewer's encryption dialog, and the file is locked with AES. Doing both locally, in your own tools, is what makes the workflow private; nothing travels to a third party that could log, leak, or store it.
What "make a password to PDF" actually involves
The phrase covers two separate problems that are easy to conflate: creating a strong secret, and using that secret to encrypt a file. Searchers often arrive thinking one tool can do both, and on some platforms it can — Adobe Acrobat's password-protect dialog will generate a password for you on the spot — but a generated-in-place password is usually short, and the algorithm behind it is opaque. Splitting the job into two stages gives you control over each half independently and lets you verify the strength of the secret before you ever touch the document.
For the first half — making the password — you want the strongest random string you can get, with no human pattern in it. For the second half — applying it — you want an encryption tool that uses a modern cipher (AES-128 or AES-256) and a known password-based key-derivation function so the resulting PDF resists offline cracking. The Password Generator handles the first half. The second half is up to your PDF viewer.
This separation also matters for privacy. If the password is generated inside the same tool that uploads your document, the vendor can see both. If the password is generated locally in your browser and then pasted into a separate desktop application, neither side ever sees the other's data. That is the architectural difference between a "make password and lock PDF" combo service and a two-tool workflow.
How password strength is measured
Strength is not a feeling. It is a number — bits of entropy — derived from two inputs you control: the length of the string and the size of the character pool you draw from. The formula is:
entropy in bits = length × log₂(pool size)
The character pool is the set of distinct symbols the generator is allowed to pick from. With uppercase, lowercase, digits, and symbols all enabled, the pool contains 86 characters, so each character contributes about 6.43 bits (since log₂(86) ≈ 6.426). That is the relationship behind every "this password is strong" meter you have seen.
| Pool name | Characters included | Pool size | Bits per character |
|---|---|---|---|
| Lowercase only | a–z | 26 | ≈ 4.70 |
| + Uppercase | a–z, A–Z | 52 | ≈ 5.70 |
| + Digits | a–z, A–Z, 0–9 | 62 | ≈ 5.95 |
| All four types | + common symbols | 86 | ≈ 6.43 |
| All four, exclude ambiguous | removes 0, O, 1, l | 82 | ≈ 6.36 |
Read the table directionally: each extra character type you add contributes a roughly constant increment in bits per character, while each additional character you append contributes more entropy than the previous step. That is why doubling length adds a much larger amount than switching character sets — and why length is the strongest single lever.
Worked example — full pool of 86 characters, length 16:
- log₂(86) ≈ 6.426
- 16 × 6.426 = 102.816
- rounded: ≈ 103 bits
That single calculation is what makes a 16-character all-types password strong against offline brute-force attacks. As a rule of thumb, under 60 bits is weak, 60 to 100 is fair, and 100+ is strong. Doubling the length to 32 characters roughly doubles the bits again, pushing the password far beyond what any current attacker can brute-force. Doubling the pool size by adding uppercase on top of lowercase adds only a constant increment per character. Length wins.
Generate the password in your browser
- Open the Password Generator in your browser. Set the length with the slider or number box (longer means stronger — 16+ is a good default).
- Move the length slider or type into the number box. For a PDF that matters, set it to 16 or higher; 20 is a comfortable default.
- Toggle the character types you want. Enabling uppercase, lowercase, digits, and symbols maximizes the pool; disabling any one type shrinks entropy.
- If you need to read or type the password by hand, leave "exclude ambiguous characters" on so 0, O, 1, and l are removed. If a password manager is doing the typing, you can disable it to keep the pool at 86.
- Read the entropy and strength meter that updates live. The number shown is the bits value from the formula above.
- Click Generate for a fresh string, or Copy to put the current one on your clipboard.
- Store the copied password in your password manager under the entry for the PDF you are about to lock.
Under the hood, the generator does three things that matter for output quality. First, the source of randomness is the browser's CSPRNG (crypto.getRandomValues), not the much faster but predictable Math.random — a distinction documented on MDN. Second, character selection uses rejection sampling rather than naive modulo, so every character in the chosen pool is selected with exactly equal probability and there is no modulo bias skewing the distribution. Third, at least one character from each selected type is guaranteed and the result is shuffled with the Fisher–Yates algorithm so the guaranteed characters do not sit at fixed positions where an attacker could exploit them.
Apply the generated password to your PDF
Generating a strong password is half the job. The other half is using it to encrypt the PDF, and the tool you choose here depends on your platform. For an in-depth walkthrough of building a hard-to-crack PDF password from scratch, see the step-by-step guide to creating a PDF password that is hard to crack. The general workflow is the same across viewers.
Adobe Acrobat (desktop). Open the file, then choose File → Properties → Security. Under "Security Method," pick "Password Security," set the compatibility level to Acrobat X (PDF 1.7) or later so the document is encrypted with AES-256, enter your generated string in both password fields, and click OK. Save the file with the same name and you are done.
Preview on macOS. Open the PDF, then File → Export → PDF. Check the "Encrypt" box and enter the password when prompted. Preview uses AES-128 by default, which is sufficient for nearly every practical threat; the resulting file is compatible with every modern reader.
LibreOffice Draw or Writer. Open or import the document, then File → Export as PDF. In the dialog, switch to the Security tab and set a user password with PDF/A or PDF 1.6 as the target format. LibreOffice applies AES-256 when configured this way.
Browser-only workflow. If you would rather not install a desktop app, several reputable in-browser tools encrypt PDFs client-side using WebCrypto. They accept a password string you provide — which is exactly why you want a strong one in hand before you start. Paste the output of the Password Generator into the password field, supply the file, and download the encrypted result.
Whichever route you take, the password you paste is the only secret. Anyone with that string can open the file, so treat the PDF password with the same discipline as any account password: unique to this document, copied once, stored in a manager, and never reused across files.
Why a CSPRNG beats human-made passwords
Humans are not random number generators. When asked to invent a password, people lean on dates, dictionary words, names, and keyboard walks — patterns that password crackers model explicitly with mangling rules. A four-word passphrase is far better than a 10-character jumble, but a string of truly random characters from a large pool is better still, because there is no model an attacker can fit to it.
The CSPRNG your browser exposes through crypto.getRandomValues is designed to produce unpredictable output from physical and operating-system entropy sources — keyboard timing, mouse movement, disk activity, and dedicated hardware where available. Its outputs cannot be reproduced from prior outputs the way Math.random's sequence can. That unpredictability is what makes a generated password suitable as a secret. According to MDN, the function is specifically intended for cryptographic use, which is the contract you want backing a PDF password.
The 86-character pool used by the Password Generator covers every printable symbol a typical PDF viewer accepts in a password field. The two-stage quality controls — rejection sampling for unbiased selection and Fisher–Yates for shuffling the guaranteed-type positions — mean the output is as close to a uniform random sample as modern browser code allows. That is why the entropy number the tool shows is a genuine lower bound on attacker uncertainty, not a marketing estimate.
Keeping the password private after you copy it
Local generation is the start of privacy, not the end. Once you click Copy, the string is in your clipboard — readable to any other application on your device that reads the clipboard, including screen readers and clipboard managers. Paste it into your password manager or directly into your PDF viewer's password field, then close the generator tab. The password exists nowhere else: not on a server, not in a log file, not in browser history (the generator runs in memory and never navigates), and not on your disk.
For long-term storage, a password manager is the standard answer. Modern guidance from OWASP's Authentication Cheat Sheet treats unique, randomly generated passwords stored in a manager as the recommended baseline for any account, and the same logic applies to document-level secrets. The PDF file itself becomes unreadable without the password and the manager becomes the only practical way to recall it.
If you do not use a manager, write the password on paper and store it with the physical document — a workable approach for paper-only workflows, but one that loses the password the moment the paper is lost. Digital workflows benefit from a manager because the password can be 16 or more characters of pure noise, which would be impossible to memorize, and the manager handles the typing for you.
Closing the browser tab discards the generator's state. Reopening the tool produces a different string. That is by design: no carryover means no leak.
If you're weighing options, How to Test Password Strength Without Uploading It covers this in detail.