Guide
How to password protect an HTML page
Updated 30 October 2026
An HTML file can’t guard itself. A password check written in JavaScript sits in the page source next to the content it hides, so anyone who opens the source reads both. Two methods work: encrypt the page so only the password decrypts it, or have the server check the password before it sends the page. On ashare.net you set a password and an optional expiry on the link, or skip the shared password and open the page only to named emails or your company.
Why a JavaScript password check fails
The snippet most tutorials offer as “HTML code to password protect a web page” looks like this:
<script>
if (prompt('Password') !== 'tulip42') document.body.innerHTML = '';
</script>The browser downloads the whole file before the script runs. The password and the report are both in that file: View Source shows them, and so does the saved file opened with scripts turned off. Hashing the password in the script changes nothing, because the content is still there as plain text. A check like this stops someone who clicked the link by mistake. It stops nobody who wants to read the page.
Encrypt the file with StatiCrypt
StatiCrypt is a free, open-source tool that turns the page into ciphertext. It encrypts the HTML with AES-256 through the browser’s WebCrypto API, stretches the password with 600,000 rounds of PBKDF2-SHA256, and writes a new HTML file with a password prompt. The reader’s browser decrypts it after they type the password, so the page has to be served over HTTPS.
$ npx staticrypt report.html -p "<a long password>"The result lands in encrypted/report.html, and you upload that file to any static host. The content is protected, with limits worth knowing:
- One password per page. Everyone shares it. To drop one reader you change the password and send the new one to everyone else, or encrypt a separate copy for each person.
- No expiry. The file opens with the password for as long as it stays online. The “Remember me” option keeps the password in the browser with no end date, unless you set a number of days.
- Offline guessing. The whole encrypted file sits in the reader’s browser, so anyone who has it can try passwords as fast as their machine allows. The README asks for 16 characters or more.
- No record of readers. StatiCrypt works without a back end, so nothing tells you who opened the page.
Let the server check the password
A link can’t carry a password by itself: the service behind it has to ask for one. With a server-side password, the page never reaches the browser until the password is right, and nobody can guess at it offline.
On your own Apache server this is HTTP Basic authentication: an .htaccess file and a password file made with htpasswd. The Apache documentation warns that Basic authentication sends the password unencrypted, so serve the page over HTTPS. Static hosts have site passwords too, each with its own plan rules: see password protection on Netlify, Vercel, GitHub Pages and others.
A password on an ashare.net link
On ashare.net the password belongs to the document, and the server checks it before it sends anything. Upload the file on My documents and type the password on the document page, or ask your agent: “Publish report.html with a password, expiring in 7 days.” From a script:
$ npx ashare-cli publish report.html --visibility public --password "<password>" --expires 7d- Each reader enters the password once per browser, and a cookie keeps them in for 7 days.
- A reader gets 10 tries a minute, so guessing is slow.
- A new password signs every reader out. That is how you lock out someone who still has the old one.
- An expiry like
24hor7dends the link: after it, readers see “Link expired”. You can extend it or remove the expiry. - ashare.net stores only a hash of the password and never takes it in the URL, so keep the password yourself.
Remove the old JavaScript check from the file before you upload it: the server does that job now. Details: Expiry and passwords.
Skip the shared password: name the readers
A password travels with the link. Whoever gets both gets in, and you can’t tell one reader from another. When you know who should read the page, give access to people instead:
- Specific people. Add up to 100 emails per document. Each reader types their email and a 6-digit code from a letter; there is no account to create. Remove an email and that person is out, the others stay in.
- Your company. A company document opens to everyone who signs in with an email on your company’s domain.
For both, you see who opened the document and when. Someone not on the list sees “You don’t have access” and can ask you in. A password still works on top: readers of a private document pass the email check first, then the password. See Sharing and access.
The options side by side
| Method | Where the check runs | Drop one reader | Expiry | Who opened it |
|---|---|---|---|---|
| JavaScript check | The browser, in readable code | No | No | No |
| StatiCrypt | The browser, on an encrypted file | New password for everyone, or a copy per reader | No | No |
| Password on ashare.net | The server | A new password signs everyone out | Yes | A count only |
| Emails or company on ashare.net | The server, per reader | Remove the email | Yes | Each reader, how often and when |
StatiCrypt is the right tool when the file must live on a host you can’t configure and one shared password is enough. When you need to drop a reader, end the link on a date or know who read it, the check has to run on a server.
ashare.net: your agent publishes HTML or Markdown and you choose who opens it: your company, specific emails or a password. Readers comment, the agent fixes the document.
Connect your agent