Updated
Password-protect an HTML page, and what a script in the page cannot protect
By João Saraiva
Search for this and the first answers are a few lines of JavaScript: a box asks for the password, and the page shows itself if the answer matches. That keeps out nobody who wants in. Here is why, and what does work.
Why a password in the page isn't one
A browser can only show what it has already downloaded. If the check runs in the page, the content arrived with the page, and usually the password did too. View Source shows both, and so does saving the page.
The common variants, and what each one leaves open:
- Hiding the content until the password is right. It is in the HTML either way.
- Checking a hash of the password, not the password. The password is hidden. The content isn't.
- Sending people to a secret page once the password matches. The secret page is a public page with an unusual address. Anyone who has the address, from a forwarded email or a browser's history, opens it without the password.
- Encrypting the content, so the page decrypts it with the password. This one does protect the content, if the password is long and random. But anyone with the file can try passwords on their own computer as fast as it allows, with nothing to slow them down. And there is no taking it back: whoever has the file and the password keeps both, and changing the password means encrypting the page and uploading it again.
What a real gate does
The check happens on the server, before the page is sent. Without the password, the server sends a form instead of the page. With it, the server remembers that this browser passed, usually with a cookie, and sends the page to every request that carries it. That means:
- The content never reaches anyone who doesn't have the password.
- Every guess goes to the server, which can slow guessing down.
- A well-built gate stores the password as a slow hash, so it can't be read back.
- Changing the password, or removing it, happens in one place.
Three ways to get one
On a server you run
Apache and nginx both have HTTP Basic authentication built in: a file of user names and hashed passwords, made with the htpasswd utility, and a few lines of configuration (auth_basic and auth_basic_user_file in nginx; AuthType Basic and AuthUserFile in Apache). The browser shows its own sign-in box. Basic authentication sends the password with every request, so use it only over HTTPS.
On a static host that offers it
Some static hosts can put a password on a whole site, often on a paid plan. Netlify, for example, offers it on its Pro plan and not on Free or Personal, according to Netlify's documentation, read on 13 October 2026. Check the plan before you count on it.
On Solta
Choose Password under who can open the site, on every plan. Solta checks the password on its own server before it sends any of the site, stores it hashed so it can't show it back to you, and limits how fast anyone can guess.
If a shared password is the weak part, choose Invited instead, on Pro and Team. Only the email addresses you name get in, each verified once by email, with no account and no password to pass around. A site behind either one can't be embedded on another website, because a frame that skipped the gate would be no gate at all.
On Free, Unlisted asks search engines not to index a site, but it is not a password: anyone with the link opens it. Who can open a site.
Whichever you choose
- Send the password apart from the link, by another channel, or you have sent one thing.
- Make it long, and don't reuse one from anywhere else.
- Serve the page over HTTPS, so the password doesn't cross the network in the clear.