Some pages are fine being public and obscure. Plenty are not: the proposal with your rates in it, the salary benchmark report, the unannounced product page, the dashboard with a client's real numbers. For those, "nobody knows the URL" is doing a lot of load-bearing work, and URLs travel. People forward things. Links sit in chat histories and browser autocomplete forever.
A password moves a page from "hidden" to "actually restricted." Here are the four practical ways to add one, from most manual to least.
1. Server-level auth (.htaccess and friends)
If you run your own server, HTTP basic auth is ancient and solid. A couple of lines of Apache or nginx config, a password file, done. The browser shows its grey login box and the server refuses everyone else.
This is the right answer when the infrastructure already exists. It is nobody's answer for sharing one page, because "first, have a server" is quite a prerequisite, and the browser's built-in auth box is a rough experience to hand a client.
2. Your hosting platform's paid tier
Netlify, Vercel and most modern hosts offer password protection as a paid feature, typically on team plans. If the page is already deployed there and someone is already paying, flip it on and you are done. If not, adding a monthly platform bill to protect one HTML file is heavy.
3. Encrypt the file itself (StatiCrypt)
A clever option for static hosts: tools like StatiCrypt encrypt your HTML with a passphrase and output a new file that is just an unlock form plus ciphertext. You can host that anywhere, even somewhere public, and the content stays sealed without the password.
The trade-offs: it is a command-line step in your workflow, re-encrypting on every edit; there is no rate limiting, so anyone can hammer guesses offline against the file; and the unlock page looks like what it is, a generic form. Real protection though, and genuinely free.
4. Share through a tool with passwords built in
The zero-infrastructure route: publish the page through a sharing service where the password is a checkbox. On commentable it is literally a field on the create screen: paste your HTML, type a password, get a link. The viewer sees a clean unlock page (with your logo on it, not ours), and wrong-guess bursts lock the page automatically.
Worth understanding what the password is added on top of. commentable pages are end-to-end encrypted regardless: the encryption happens in your browser and the key travels in the link fragment, which never reaches our servers. So the base link is already unreadable to us and to anyone without the exact URL. The password is the second layer, for when the URL itself might wander: forwarded emails, shared inboxes, a link pasted into the wrong Slack channel.
Layers, not silver bullets
A sensible stack for a confidential page you are sharing outside your org:
- Encrypted link, so the content is not sitting readable on someone's server.
- Password, sent on a different channel than the link.
- Expiry date, so the whole question evaporates when the project ends. A link that no longer exists is the only link that cannot leak.
That last layer is underrated. Most shared pages have a natural lifespan of weeks, and an expiry matched to it costs nothing today while deleting a risk permanently. On commentable, expiry is on by default and you get an email before anything vanishes.
If the page you are protecting is client work headed into review, the feedback guide covers the rest of that workflow, passwords included.