Guide · Updated October 10, 2026 · 7 min read
How to password protect a web page
The short answer
To password protect a web page, or a whole website, the password check must happen on the
server, before any content is sent to the browser. You can do this with server configuration
(like .htaccess on Apache), with your hosting platform’s built-in protection, or
with a publishing service such as Pagelive that enforces a hashed password at the edge.
JavaScript-only prompts don’t qualify: the page has already been delivered.
The options, ranked
Four ways to password protect a page, ranked honestly
Server configuration (.htaccess / basic auth)
On a server you control, you can require a password before the server responds at all: .htaccess plus .htpasswd on Apache, auth_basic on nginx. It’s genuine protection because the check happens before any content leaves the server. The trade-offs: you need server access and config skills, the browser shows a bare system prompt rather than a branded page, it usually protects a whole directory rather than a single page, and it doesn’t exist at all on most static or drag-and-drop hosts.
Your hosting platform’s built-in protection
Some hosting platforms offer password protection as a feature. When the platform enforces the check on its servers before serving the page, this is real protection. Two things to verify: that the gate runs server-side (not a script in the page, see option 4), and what it covers. It’s often site-wide rather than per-page, and frequently reserved for higher-priced tiers.
A publishing service with an edge-enforced gate
Services built for sharing private pages enforce the password at the edge: the request is stopped at the CDN, before the page is served, with no server of your own to configure. On Pagelive you set a password per page when you publish (or any time after); it’s hashed before storage, so we can’t see it, and the page is also kept out of search by default. Setup is the time it takes to type the password.
JavaScript-only “protection”
Tutorials abound for a password prompt written in JavaScript: the page loads, a script asks for a password, and shows the content if it matches. The problem is the order of events: by the time the script runs, the full page has already been delivered to the browser. Anyone can read it with View Source or by turning JavaScript off, the password itself often sits in the page code, and search engines can index the content behind the prompt. It’s a curtain, not a lock: fine for a playful easter egg, never for anything confidential.
Worth understanding
Why a JavaScript prompt isn’t a lock
It’s worth being precise about this, because the JavaScript approach looks identical to the real thing from the visitor’s side. The difference is invisible but decisive: with a server-side or edge-enforced gate, the server refuses to send the page until the password checks out. With a JavaScript prompt, the server has already sent everything: the script just hides it. Hidden is not protected. View Source shows the content, disabling JavaScript shows the content, and a crawler that ignores scripts reads the content. None of this requires any skill; it’s a right-click.
So the rule of thumb: if you could not comfortably email the page to a stranger, don’t rely on a script to guard it.
The fastest real option
Password protect a page in three steps, no server
Publish the page
Upload the file at app.pagelive.io, or say “publish this” in Claude. You get a live link in seconds. No server, no config.
Set the password
Add a password at publish time or later from the page’s settings. It’s hashed (PBKDF2) the moment you save it: nobody at Pagelive can read it.
Share the link
Send the link, and the password separately if you like. The gate is enforced at the edge before any content is served, and your view tracking keeps working.
The full feature (what the gate looks like to your recipient, changing or removing the password, what happens if it’s forgotten) is on the password-protected pages page. And the password is one layer of several: here’s how Pagelive keeps pages private end to end (noindex by default, content served separately from your account, on SOC 2 Type II-ready infrastructure on Cloudflare).
Frequently asked
Use a publishing service that enforces the password before the page is served. With Pagelive you upload your HTML, set a password, and share the link. The check runs at the edge, the password is hashed, and the page stays out of search by default. No server, no .htaccess, no code.
No. A JavaScript prompt runs after the page has already been delivered to the browser, so the content is one View Source away, and the password often sits readable in the page code. For real protection the check must happen on a server or at the edge, before any content is sent.
.htaccess works if you run an Apache server and can edit its config, but it typically protects a directory, not one file, and static hosts don’t support it. The simplest route for a single file is a service with per-page passwords: publish the file, set the password, done.
Both are real protection, because both check the password before serving content. .htaccess runs on your own Apache server and needs config access; an edge-enforced gate runs on the CDN in front of the page, so it works without any server of your own and can show a branded password page instead of a bare browser prompt.
A real server-side or edge-enforced password stops crawlers from reading the content, but the URL itself can still be listed if the host allows indexing. Pagelive pages are also noindex by default, so the locked page isn’t sitting in search results inviting attempts.
Want the one-switch version? See password protected pages on Pagelive. Related guides: how to share an HTML file as a link · share a Claude artifact without a login. Sending client proposals? See AI proposal software. More in the guides library.