Password Protect PDF — Encrypt PDF Files Online for Free

A contract, a passport scan, a medical statement, a financial report — documents you can't leave open. The "Password Protect" tool in pdfredX encrypts a PDF right in the browser: without the password the file won't open in any compliant viewer. Neither the document nor the password goes to a server.

Step 01. Upload the PDF

Open pdfredx.com and add the document you need to protect. The file is read locally in the tab — nothing is sent to a server.

Step 02. Set a password

Turn on password protection and enter the password twice (to confirm). The rules are simple: at least 6 characters, and both fields must match. Choose a strong password — all the protection rests on it, and it cannot be recovered if lost (the file would be impossible to open).

Step 03. Download the protected PDF

Press "Create PDF". The document is assembled already encrypted, and the file name gets a _protected tag. When anyone tries to open it, any viewer — Adobe, a browser, a mobile app — will ask for the password first. The download goes straight from the browser. Free, no registration.

How it works under the hood

The password is passed to the jsPDF constructor via the encryption option — the document is created right away with standard PDF encryption (RC4) enabled. This is not a "lock on top of the file" or a script stub: the content itself (the page streams) is encrypted, and an /Encrypt dictionary is written into the PDF structure. That's why the password is required by any compliant viewer, not just one particular app. All of this happens in the tab's memory — the password and the file never leave the device.

Known limitations

The password can't be recovered. We don't store or transmit it — if you forget it, the document can't be opened. Write the password down in a safe place.

Encryption is RC4 128-bit, not AES-256. This is real "password to open" encryption, compatible with all viewers, and it's enough to keep an outsider from opening the file. But RC4 is a legacy algorithm: against a targeted attack with specialized tools it's weaker than modern AES. For especially sensitive documents, use the password as one layer, not the only measure.

Strength of protection = strength of the password. A short or obvious password is broken by brute force. Use a long password of random characters.

Need to place a visible "Copy" mark or a logo rather than lock the file? That is the Watermark tool.

Try it right now — pdfredx.com, no registration, your files stay with you.

You put a password on a PDF so an outsider can't open the document. But an ordinary online "password-protect PDF" service is built so that you have to upload both the document and the password you chose to its server. That's a paradox: while protecting the file, you hand both its contents and the key to it to someone else's machine. Let's look at the risk and at the local alternative.

The paradox of server-side password protection

The point of a password is that no one but you has access to the document. Yet a server service that sets this password receives both the file in the clear and the password. From there, by the service's policy, they can:

• be stored in a contractor's temporary storage (AWS, GCP, Azure);
• be processed on someone else's server;
• be logged together with metadata — IP, time, file name.

Even if the service is honest, you're forced to trust it with both the document and the key. For contracts, scans with personal data and financial reports, that is exactly the risk the password is meant to protect against.

Local encryption: the password and the file never leave the device

pdfredX encrypts a PDF without uploading either the file or the password anywhere.

The file is read locally. The document opens in the tab; there is no network request carrying it.

The password stays in the tab's memory. It's passed straight into jsPDF encryption and is not stored anywhere — not by us, not on the network.

Encryption runs on the client. The document is assembled already encrypted (standard PDF encryption), and an /Encrypt dictionary is written into the file — it can't be opened without the password in any compliant viewer.

It works offline. Load the file, turn off the internet and set the password — everything keeps working. The network is only needed to load the app once.

In practice: turn on protection, enter the password twice, press "Create PDF" — you get an encrypted file. Both the document and the password stay only with you the whole time.

Honestly about the limitations

Encryption is RC4 128-bit, not AES-256. This is real "password to open" protection, compatible with all viewers, but RC4 is a legacy algorithm and weaker than AES against a targeted attack. For especially sensitive documents, combine the password with other measures.

The password isn't recoverable. We don't store it — forget it, and the file can't be opened.

Local processing isn't a shield against everything. Malware on the device, browser extensions with broad permissions and an unencrypted disk remain outside our control. We provide isolation at the level of the browser tab; the rest is on the user's side.

Set a password without uploading the document to a server — pdfredx.com, free, no registration.

"Put a password on a PDF" can mean very different things — from honest content encryption to an imitation that only pretends to protect. The difference is critical: some methods require the password in any viewer, others are bypassed in two clicks. Let's break down how password protection in pdfredX is built: why encryption is set in the document constructor, what goes into the /Encrypt dictionary, and where the line between RC4 and AES-256 runs.

What "real" PDF encryption is

The PDF format has a built-in security mechanism (the Standard Security Handler): the content (page streams and objects) is encrypted, and an /Encrypt dictionary with parameters is added to the document structure. A viewer that encounters /Encrypt must ask for the password and decrypt the data with a key derived from it. The key point: the content itself is encrypted — without the password there is no readable text or images in the file.

This is fundamentally different from "soft" fakes — for example, JavaScript embedded in a PDF that shows a password box and closes the document. Such a script works only in viewers that execute PDF JS (Adobe Acrobat), while the content sits in the clear and can be read by any other tool. pdfredX uses exactly the built-in encryption, not a script stub.

The implementation, piece by piece

Encryption is set when the document is created

The engine's key constraint: encryption in jsPDF is enabled only in the constructor, not after the fact. So the password is requested and validated before the document is created, then passed into the options:

const pdfPwd = getPdfPassword();               // ≥6 chars, confirmation matched
const pdfOpts = { orientation, unit: 'mm', format: 'a4' };
if (pdfPwd) pdfOpts.encryption = { userPassword: pdfPwd, ownerPassword: pdfPwd };
const pdf = new jsPDF(pdfOpts);                // the document is created already encrypted

userPassword is the password to open, ownerPassword the one for changing permissions; here they're the same (a simple "password to open" model). Pages are then added as usual, but on output (pdf.output) all streams are already encrypted, and /Encrypt is written into the structure.

Verifying the result

That an encrypted document is actually encrypted is visible right in the bytes:

const bytes = pdf.output('arraybuffer');       // look for /Encrypt and a plaintext leak
// in the result: "/Encrypt" and the Standard handler are present,
// while the content marker string is ABSENT from the bytes — the content is encrypted.

That's exactly how the behavior was tested: in the encrypted file the marker string isn't found, in a plain one it is. The password is required by any compliant viewer, not just Acrobat.

Everything local

The password is passed straight into jsPDF in the tab's memory and is not stored anywhere. The file is assembled on the client — neither the document nor the key goes to the network.

RC4 vs AES-256: the honest line

jsPDF implements the standard security handler on the RC4 (128-bit) algorithm. This is real encryption, compatible with all viewers, and it reliably closes the document off from casual and ordinary access. But RC4 is a legacy stream cipher: against a targeted attack with specialized tools it is weaker than modern AES-256, which recent versions of the PDF standard use.

The honest conclusion: for "so an outsider can't open it," an RC4 password is fine; for documents where the cost of compromise is high, it should be one layer of protection, not the only one. AES-256 client-side requires a different crypto library — a possible next step.

Trade-offs and boundaries

The password is unrecoverable — it's stored nowhere; forget it and the file can't be opened.

Strength = strength of the password. RC4 or AES, a short password is broken by brute force. You need a long random password.

Doesn't protect against on-device threats — malware, extensions, an unencrypted disk are outside the browser tab's control.

What's next

AES-256 — moving to the modern algorithm via a separate crypto library for higher-sensitivity documents.

Access permissions — a separate owner password with fine control (no printing/copying) on top of the open password.

Test it on your own document — pdfredx.com, no registration, the file and password stay with you.