How to Password-Protect a Website or a Single HTML Page

There are three ways to password-protect a website, and only two of them protect anything. A password checked by your host's server holds back every page and file until the visitor types it; a page encrypted with a free tool such as StatiCrypt or PageCrypt can sit on any host and unlocks in the visitor's browser; a JavaScript prompt or an unlisted link only hides the page from people who don't look. For a whole site, or a single page you can publish at its own address, use the host's password (Statpio includes one on every plan, Free Forever too); for a file that has to stay on a host that has none, encrypt it.

Disclosure: this guide is published by Statpio, one of the tools compared. We link every competitor fact to its official source.

Which way of password-protecting a website should you use?

Source: each tool's official documentation, linked in the sections below, as of November 2026.

How do you password-protect a website on Statpio?

Statpio checks the password before it sends any page or file, on every plan, Free Forever included:

1. Open the website in the dashboard, then Settings.
2. Open Password Protection.
3. Type a password of 8 to 128 characters in Set a site password and click Enable.
4. Send the address and the password to the people who should see the site, ideally in separate messages.

To open the site to everyone again, click Remove and confirm. If you build with an AI assistant, it can do the same through Statpio's connector at https://statpio.com/mcp: ask it to put a password on the site, or to take it off.

• It covers the whole website: every page, image and file, the blog and the forms' own links, on the onstatpio.com address and on your own domain.
• Visitors stay signed in for a day, then the site asks for the password again.
• The password is stored as a salted hash, not as the password itself, and repeated wrong guesses are slowed down: after too many, the visitor has to wait a few minutes.
• Protected pages are never kept in public caches, and search engines only ever see the password page, which asks them not to index it.
• A new password signs everyone out. Click Remove and set a new one straight away, or ask your assistant to replace it in one step: everyone who used the old one has to type the new one.
• Only the account owner can set or remove it. Collaborators can't, and the activity log records each change.
• The password page carries your brand, or none. It has no Statpio branding on paid plans, and on Agency Pro it shows your agency's logo (or name) with your colour on the button; on Free Forever it shows the Statpio logo.

What it doesn't do: it protects a whole website, not one page, and everyone shares the same password, with no separate accounts per visitor. For one private page beside a public site, publish that page as its own website with its own password (Free Forever has 1 website, Solo Pro has 5), or encrypt that one file with StatiCrypt or PageCrypt as described below. The features page lists what each plan includes, and if this is your first site, our guide to hosting an HTML website for free, with forms and analytics covers the upload and the free address.

How do you password-protect a Netlify, Vercel, Cloudflare Pages or GitHub Pages site?

As of November 2026, the big free hosts handle it very differently:

Source: Netlify password protection and pricing, Vercel Password Protection and Pro plan, Cloudflare Pages preview deployments and Cloudflare Access pricing, GitHub Pages visibility, and Statpio's from the product, checked 9 November 2026.

Netlify

As of November 2026, Netlify's docs say "Basic password protection for your entire site is available on all Pro plans" and that "Password protection isn't available on Credit-based Free and Personal plans". The basic option shows visitors a generic prompt for one shared password; team login asks them to sign in as members of your Netlify team. On Free and Personal the alternative is a private project, which on those plans "is visible only to the Team Owner": fine for your own drafts, not for a client review.

Vercel

Password Protection is a Pro and Enterprise feature. As of November 2026, on Pro it costs $20 a month for each project you protect, on top of the $20 a month Pro platform fee; Enterprise includes it, and Hobby doesn't have it. Turn it on in the project's Deployment Protection settings, and pick All Deployments as the scope if the live site should be private, because the default, Standard Protection, leaves production domains public. The free alternative on every plan, Vercel Authentication, asks visitors to log in with a Vercel account that has access, and a Hobby account can grant that to only one external user.

Cloudflare Pages

Pages protects sites through Cloudflare Access rather than a password. Its Enable access policy option, under Settings > General, restricts viewing deployments to your Cloudflare account, and Cloudflare notes that it only protects preview deployments, not the *.pages.dev address or a custom domain. Protecting those means setting up a Cloudflare Access application, as the Pages known issues page explains. Access signs people in rather than asking for one password, for example with a one-time PIN sent to approved email addresses, and as of November 2026 it's free for up to 50 users. It suits a team; for a quick client review it's more set-up than a password.

GitHub Pages

GitHub's docs warn that "GitHub Pages sites are publicly available on the internet, even if the repository for the site is private". Its only access control is private publishing for organisations on GitHub Enterprise Cloud, where "a privately published site can only be accessed by people with read access to the repository". Everyone else encrypts the page before publishing it (next section) or puts the private part on a host that checks a password.

An Apache server with .htaccess

On shared hosting that runs Apache, a .htaccess file can switch on Basic authentication for a folder, if the server allows it: Apache's guide says that needs AllowOverride AuthConfig in the server configuration. The same guide warns that "Basic authentication sends the password from the client to the server unencrypted", so only use it on a site served over HTTPS.

How do you password-protect a single HTML page for free?

There are two ways, and the simpler one needs no extra tool: publish the page as its own small website on a host that checks the password on the server. On Statpio that's free. Put the page in a ZIP as index.html, publish it on the Free Forever plan and turn on Password Protection, as described above. The page gets its own address, and nothing is sent to a visitor until the password is right. If your public site already uses your 1 website on Free Forever, a second website needs Solo Pro, which includes 5.

The other way keeps the page where it is: encrypt it. StatiCrypt and PageCrypt are free, open-source tools that turn an HTML file into a new one holding the encrypted content and a password box. When a visitor types the right password, their browser decrypts the page; nothing is checked on a server, so the result works on any host, GitHub Pages included. Use it when the page has to stay on a host that has no password of its own.

• StatiCrypt "uses AES-256 and WebCrypto to encrypt your HTML file", with 600,000 rounds of PBKDF2-SHA256 to slow guessing down. You can encrypt a file in your browser on its website or from the command line, and it can encrypt a whole folder of pages.
• PageCrypt also uses the browser's Web Crypto API (AES-GCM, with a key derived through PBKDF2, in its source code), from the command line or as a step in a build.

# StatiCrypt: asks for the password, then writes encrypted/page.html
npx staticrypt page.html

# PageCrypt: writes an encrypted copy (a password typed here can stay in your shell history)
npx pagecrypt page.html page-protected.html "a-long-unusual-password"

What client-side encryption can't do:

• It's only as strong as the password. The encrypted file is public, so anyone can download it and try passwords on their own computer, as fast as it allows. StatiCrypt's README puts it plainly: "brute-force/dictionary attacks would be easy to do at a fast pace: use a long, unusual password", and it recommends 16 or more letters and numbers.
• It protects the HTML, not the files beside it. StatiCrypt copies non-HTML files "as-is", and PageCrypt "only encrypts the contents of a single HTML file", so images, PDFs and scripts the page links to stay public at their own addresses unless you inline them.
• One password per page, and no taking it back. StatiCrypt supports one password per page. Changing it means encrypting and publishing again, and anyone who saved the old file can still open that copy with the old password.
• It needs HTTPS. StatiCrypt's current version relies on WebCrypto, which is "only available in HTTPS or localhost contexts".
• Staying unlocked trades safety for convenience. StatiCrypt's "Remember me" box keeps a salted hash of the password in the browser's local storage, and PageCrypt keeps the derived key in session storage until the browser restarts, so whoever uses that device can open the page.

StatiCrypt's author is candid about the limits too: "I am not a cryptographer", and if you are "an at-risk activist or have very sensitive crypto assets to protect, you might want to use something else".

Can you use StatiCrypt or PageCrypt on Statpio?

Yes, both work as they are: encrypt the page, put the result in your site's ZIP and publish it. Statpio leaves any form with a password field alone, so it adds no security check to the password box and never collects what's typed there. One thing to know: Statpio sets up contact forms on the page it serves, which for an encrypted page is the password box, not the content behind it. Keep contact forms on pages you don't encrypt.

Why isn't a JavaScript prompt or a hidden link real protection?

Because the page is sent to anyone who asks for it. A script that asks for a password before showing the page has the page, and usually the password, inside the file the browser has already downloaded, and "view source" or the browser's developer tools show both. An unlisted address works only until it's forwarded, pasted into a chat or linked from somewhere, and anyone who has it can open the page. Search engines aren't a lock either: Google says a robots.txt file "is not a mechanism for keeping a web page out of Google", and that a page marked noindex "can still be linked to and visited". For confidential content, Google's advice is to password-protect it so only authorised users can reach it.

How do you share a password-protected preview with a client?

For a new site, publish it, turn on the password, and send the client the address and the password separately; remove the password at launch. For a redesign of a site that's already live, upload the new version to the website's staging address instead (Solo Pro and up): the website's password covers that address too, and when the client approves, Publish to live puts that exact version live without uploading it again (how staging works). Then work through our website handover checklist, so the client ends up with the domain, the logins and everything else they need.

To try the server-side option on your own site, start free: Free Forever includes 1 website on a free onstatpio.com address, with password protection, forms and visitor statistics.