Guide · Updated June 12, 2026 · 7 min read
How to password protect a web page
There are four common ways to put a password on a page — and one of them isn’t protection at all. Here’s the honest ranking: what each option actually guards against, what it takes to set up, and how to pick.
The short answer
To password protect a web page, 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 an encrypted 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
The test that separates them: does the password check run before the page is served, or after it’s already in the visitor’s browser?
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 encrypted 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
If you don’t run your own server (or don’t want to), this is the whole process on Pagelive — free for up to 10 pages.
Publish the page
Paste your HTML, drop the file, or say “publish this” in Claude. You get a live pagelive.site 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 encrypted (PBKDF2-hashed) 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 Cloudflare’s SOC 2 Type II infrastructure.
Frequently asked
How do I password protect a web page without a server? +
Use a publishing service that enforces the password before the page is served. With Pagelive you paste or drop your HTML, set a password, and share the link — the check runs at the edge, the password is encrypted, and the page stays out of search by default. No server, no .htaccess, no code.
Is JavaScript password protection safe? +
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.
How do I password protect a single HTML file? +
.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.
What’s the difference between .htaccess and an edge-enforced password? +
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.
Does a password keep the page off Google? +
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.
More on sharing pages privately in the guides library.
Put a real lock on your next page.
Edge-enforced password, encrypted so we can’t see it, kept off Google by default. Free to start.