Drop a file, set a password, get one protected .html back. Nothing is uploaded.
Drop an HTML file and type a password. Your browser derives a key from it with PBKDF2-HMAC-SHA-256 over a random salt (310,000 iterations), encrypts the document with AES-256-GCM under a random one-time IV, and builds a new HTML file containing the ciphertext plus a small unlock screen. You download that file.
The result is one ordinary .html with no dependencies — email it, or put it on any static host. Whoever opens it sees a password box; the page only renders after the right password decrypts it in their browser, and nothing is checked against a server because there is no server involved. One requirement to know about: browsers only expose the encryption API in a secure context, so the file has to be served over https (localhost counts). If it is opened in a way that does not qualify, the page says so rather than sitting there.
Everything happens locally. The file is read with the File API, encrypted with WebCrypto, and handed back as an in-memory blob. It is never sent anywhere, which is the point when the document is an unreleased report or a client deliverable.
Encrypt the page itself and ship the unlock screen with it. Drop the file above, set a password, and you get one self-contained HTML back: the original document is encrypted with AES-256-GCM and the new file contains that ciphertext plus a small script that asks for the password and decrypts in the reader's browser. No .htaccess, no backend, no host configuration — it works on any static host. It does need to be served over https, because that is where browsers make the encryption API available.
It is real encryption, not hiding. The content is AES-256-GCM ciphertext; without the password the bytes are not recoverable, and a tampered file fails to decrypt rather than decrypting into something wrong. The honest limit is different: because the ciphertext is inside the file, someone who has the file can guess passwords offline without you ever knowing. So the strength of the protection is the strength of your password, and that is why the key derivation is deliberately slow.
Long and unusual beats short and clever. A four-word passphrase you can actually send someone is far stronger here than an eight-character password with symbol substitutions, because the attack is bulk guessing rather than a human staring at the box. Avoid anything that appears in a breach list or that relates to the document — the filename, the client's name, the project.
Neither. The password never leaves your browser: it is turned into a key locally and used to encrypt the file locally. It is not in the downloaded file either — only the salt, the IV, and the ciphertext are, which is what makes decryption possible for someone who knows the password and impossible for someone who does not.
The mechanism is the same idea, and those are good tools with a long track record — if you already use one, there is no reason to switch. This one runs in the browser with nothing to install, produces one file, and is built by people whose actual product is the other half of the job: getting that file to someone. The FAQ below on links versus files is the part worth reading before you pick either.
It depends on what you need after you send it. A protected file is right when the file itself has to travel — an email attachment, a USB stick, a host you do not control, somewhere offline. A private link is right when you may need to change your mind: revoke access, rotate the password, replace the contents, set an expiry, or see whether it was opened. A file cannot do any of those, because every copy is independent the moment it leaves you. Many people use both — the link for the normal case, the encrypted file when it has to be a file.
Yes. The original document is restored in full before it renders, so scripts, styles, charts, and event handlers behave exactly as they did. The one thing that changes is the first moment: the reader sees a password box instead of the page.
This tool caps at 25 MB, which is a browser-memory limit rather than a policy — it runs in your tab. Encryption adds roughly a third to the size, because ciphertext is carried as base64 text. If your page is heavy because images are inlined as base64, linking the images instead will shrink it far more than anything else you can do.