Can I password protect an HTML file without a server?

Only with client-side tricks: a JavaScript prompt that checks the password, or a tool like PageCrypt that encrypts the HTML body and asks for a passphrase to decrypt it locally. These are real protection if the attacker only has the file, but anything served over the web can be inspected by viewing the page source or opening browser devtools. For real server-side protection, the password check has to happen on the server before the HTML is sent.

Is JavaScript password protection for HTML files secure?

No, not when the file is hosted on the open web. A JavaScript check is enforced in the browser, so the attacker can open the page source, find the password (or the encrypted body and decryption logic), and recover the content. PageCrypt-style encryption is stronger because the body itself is encrypted, but it still ships the ciphertext to anyone who loads the page, so an offline attack is always possible.

How does LiveSend password protection work?

The password is hashed with bcrypt and stored alongside the document. When a viewer hits the URL, the server requires the password before returning any HTML. Successful unlock sets a short-lived cookie so the viewer does not re-enter the password on every refresh. The HTML body is never sent to the browser until the password matches. This is server-side gating, which is the only model that actually keeps the content out of unauthorized hands.

Can I set an expiration date on a password-protected HTML link?

Yes on services that support it. LiveSend lets you set an expiration date independently of the password, after which the URL stops serving the document (the viewer sees an expired page). Tiiny.host has similar controls on paid plans.

What if the recipient shares the password with someone else?

A password by itself does not bind to a recipient. If you need per-recipient access control, combine the password with an email gate that captures the viewer email on first visit. LiveSend supports both at once: the password is required to unlock, and the email gate logs which email opened the document. For full identity-bound access, you would need a real account-based access control system.

How to password protect an HTML file

Two completely different things called "HTML password protection"

When people search for "password protect an HTML file", they end up on tutorials that fall into one of two categories, and the distinction matters a lot. The first category is client-side: a JavaScript snippet embedded in the file that pops a prompt asking for a password. The second category is server-side: the server hosting the file refuses to serve it until the password matches. Client-side is obfuscation. Server-side is protection. Tutorials rarely make this clear.

Why client-side "protection" is fragile

A JavaScript password check looks like this: when the page loads, a script asks for a password, compares it to a stored value, and reveals the body if it matches. The problem is that everything the browser knows, the user knows. Right-click, view source, and the entire HTML (including the password check) is visible. Slightly more sophisticated schemes encrypt the page body so that viewing the source only shows ciphertext (PageCrypt does this), but even then the ciphertext is on the user's machine, so an offline brute-force attack is possible if the password is weak.

Use it when:the protection is decorative, the audience is non-adversarial, and the content is not actually sensitive. Useful for "keep grandma out of the gift page", not useful for client deliverables.

Option 1, LiveSend server-side password

On LiveSend Pro, every document can be protected with a password you set in the dashboard. The password is hashed with bcrypt before storage. When a viewer visits the URL, the server checks the cookie. If absent or invalid, the server returns a password prompt and never sends the document HTML. Submitting the correct password sets a 24-hour cookie. This is server-side gating, which is the model that actually keeps content out of unauthorized hands.

Combine it with the email gate (also on LiveSend Pro) to capture the viewer email on first unlock. That way you know not only that the document was opened, but by whom.

Option 2, Tiiny.host password

Tiiny.host offers password protection on its paid plans. The mechanism is server-side, same model as LiveSend in principle. Tiiny.host does not include a per-viewer email gate, so you get aggregate view counts but cannot tie a specific view to a specific recipient by default.

Option 3, Static.app password

Static.app supports basic-auth gating for static sites on paid plans. It is targeted at developers and the dashboard assumes familiarity with build artifacts and CLI tools, but the underlying protection is real server-side gating.

Option 4, encrypt the file with a third-party tool

Tools like PageCrypt encrypt the HTML body with a passphrase and embed it inside a wrapper page. The wrapper asks for the passphrase on load and decrypts the body locally with WebCrypto. Useful for offline distribution (you can email the encrypted .html as an attachment, and only someone with the passphrase can open it). On the open web it is still vulnerable to offline brute force if the passphrase is weak.

When passwords are not the right tool

Passwords add friction but they do not bind to an identity. If the recipient forwards the URL and password together, the next viewer is in. For deals with NDAs, M&A data rooms, or anything where identity-bound access matters, you want a virtual data room (DocSend Advanced, Firmex, Intralinks) rather than a password on a static HTML page.

Picking the right option

Real confidential client work, want server-side gating plus per-viewer tracking: LiveSend. Just need a password on a static site: Tiiny.host. Encrypting for offline distribution: PageCrypt or similar. Identity-bound access for regulated transactions: a proper VDR, not a password.

How to password protect an HTML file before sharing