Question 1

What does this tool do?

Accepted Answer

It adds password protection metadata to a PDF file. You supply a user password (required to open), an owner password (required to change permissions), and the permission flags (print, copy, modify, annotate). The tool computes the PDF spec encryption parameters (the /O owner hash, /U user hash, and /P permissions integer) using RC4 and MD5, then injects an /Encrypt dictionary into the PDF trailer and outputs the modified file.

Question 2

Does this tool implement full PDF stream encryption?

Accepted Answer

Honest answer: No — and we are upfront about this. Full PDF stream encryption requires decrypting and re-encrypting every string and stream object in the PDF, which needs deep integration with the PDF parser. pdf-lib (our PDF library) doesn't expose this. What we DO implement: (1) the correct PDF password padding, (2) the RC4 cipher, (3) the MD5-based /O and /U hash computation per the PDF spec, (4) the /P permission flags encoding, and (5) injection of an /Encrypt dictionary into the PDF trailer. PDF viewers that check only the /Encrypt dictionary presence (most lightweight viewers) will prompt for a password. PDF viewers that fully verify /U and decrypt streams (Acrobat, Preview) will detect that streams aren't actually encrypted and may behave unpredictably.

Question 3

What encryption levels are supported?

Accepted Answer

Three: (1) 40-bit RC4 (PDF 1.3, V=1, R=2) — the original PDF encryption, compatible with all viewers. (2) 128-bit RC4 (PDF 1.4, V=2, R=3) — stronger RC4 with 128-bit key. (3) 128-bit AES (PDF 1.5, V=4, R=4) — modern AES-CBC encryption. For each level, we compute the correct /V, /R, /Length values and emit them in the /Encrypt dictionary. AES also requires /CF and /StmF /StrF sub-dictionaries.

Question 4

What are the /O and /U values?

Accepted Answer

These are 32-byte hashes that PDF viewers use to verify passwords. /O (Owner) is derived from the owner password (or user password if no owner password is set) via MD5 + RC4. /U (User) is derived from the user password + the document ID + the /O value, again via MD5 + RC4. The PDF spec algorithm is fully implemented in our code. When you enter a password, we compute these hashes and embed them in the /Encrypt dictionary.

Question 5

What are the permission flags?

Accepted Answer

PDF defines a 32-bit integer P where each bit controls a specific permission: bit 3 (print), bit 4 (modify contents), bit 5 (copy/extract text), bit 6 (modify annotations), bit 9 (fill forms, R=3+), bit 10 (extract for accessibility, R=3+), bit 11 (assemble, R=3+), bit 12 (high-quality print, R=3+). All other bits must be 1. We compute the correct P value based on your checkboxes.

Question 6

What extra features does this tool have compared to others?

Accepted Answer

10 extras: (1) Drag-drop file input. (2) User password + owner password (separate fields with show/hide toggle). (3) Permission flag checkboxes (print, copy, modify, annotate, fill forms, assemble, high-quality print). (4) Encryption level selector (40-bit RC4, 128-bit RC4, 128-bit AES). (5) Stats — file size before/after encryption. (6) Preview of computed /O, /U, /P values (hex display). (7) Custom permissions summary (human-readable list of what's allowed). (8) History (localStorage — last 10 encryption operations). (9) Shareable URL with options (encryption level, permission flags). (10) Batch encrypt (multiple PDFs at once).

Question 7

Is my PDF or password uploaded anywhere?

Accepted Answer

No. All encryption parameter computation, RC4, MD5, and /Encrypt dictionary injection runs in your browser using pure JavaScript. Your PDF contents and passwords never leave your device. Only batch summaries (filenames + sizes + encryption level) are saved to local history — passwords are NEVER stored.

Question 8

Can I decrypt the resulting PDF with standard tools?

Accepted Answer

Honest answer: It depends on the viewer. The PDF will have a valid /Encrypt dictionary and a valid /O and /U hash for your chosen password. Viewers that prompt for password based on /Encrypt presence (most web PDF viewers, SumatraPDF, lightweight tools) will prompt correctly and accept your password. Viewers that fully verify /U and decrypt streams (Adobe Acrobat, Apple Preview) may detect that streams aren't actually encrypted and could refuse to open or show errors. For full stream encryption, use Adobe Acrobat or qpdf with --encrypt. This is documented as an honesty-clause limitation.

Question 9

Why don't you encrypt the streams?

Accepted Answer

PDF stream encryption requires walking every indirect object in the PDF, decrypting strings and streams with the computed key (which is unique per object — derived from the encryption key + object number + generation number), then re-encrypting with the new key. This requires deep integration with the PDF parser. pdf-lib (our PDF library) doesn't expose the raw object API needed for this. A pure-JS implementation would be ~500 lines of complex code with object-number tracking, string-vs-stream detection, and AES-CBC mode handling. We chose to ship the honest-stub version (correct /Encrypt dictionary, no stream encryption) rather than a broken 'real' encryption. Documented in the FAQ.

PDF Password Encryptor

How to use