How to Password Protect a Website: 5 Methods (No Dev Needed)

You want to password protect a website. Usually that means one of three jobs: a client preview before launch, a staging site shown to stakeholders, or a personal page like a wedding site that shouldn't show up in Google. Same need each time - a real wall in front of the URL, not a hard-to-guess link.

Most guides give you five methods and let you pick. This one tells you which to pick - and why an email whitelist beats a shared password for almost every real use case. If you need to password protect website content fast and don't want to learn Apache, this is the field guide.

Want to skip the field guide and just ship a gated preview? Drop your files at hostsmith.net and turn on a password on the Starter plan. Done.

On Vercel, Netlify, Framer, Webflow, GitHub Pages, or raw HTML? Jump to the platform-specific walkthroughs below.

Obscured is not protected

Quick definition before anything else, because most people get it wrong.

Obscured = the URL is hard to guess. Think Google Drive share links, unlisted YouTube videos, or those random Notion URLs with the long hash.

Protected = the server actually checks who you are before sending bytes.

The difference matters. An obscured URL leaks. People paste links in Slack, forward emails, save bookmarks that sync across devices. Some browsers send URLs to safe-browsing services. One screenshot in a group chat and your "private" link is in the wild.

If a client preview ever leaks before launch, it's almost always because someone treated obscurity as security. Don't.

Why password-protect a website at all?

The five situations that come up over and over:

• Password protect client preview sites for design or web work
• Password protect staging site builds before they go public to stakeholders
• Wedding or event sites you don't want to show up in Google
• Internal documentation that doesn't need full SSO
• Paid-content gates (one shared password to a private guide or PDF)

Different stakes, same need: a wall in front of the site. The wall is what separates "password protect website" from "use a long URL and hope."

Shared password vs email whitelist: pick one before you pick a method

Before you choose a method, choose a model. Almost every option below supports one of two:

Shared password. One string everyone types. Simple, instant, no accounts. Two real problems: it forwards (one screenshot of the email and the wall is gone), and the only way to revoke is to rotate the password and re-send it to every legitimate viewer. For a wedding site with 80 guests, that's fine. For a client preview that goes through three rounds of revisions, it's tedious by round two.

Email whitelist. You paste a list of emails. Those people get a magic link (or sign in with Google / Microsoft / GitHub depending on the system). Revoking one person is one click. Adding a fourth reviewer mid-project doesn't disturb the first three. There's no password to forward, because there's no password.

Hostsmith Private Sites supports both, on the Starter plan and up. Cloudflare Access is email-whitelist by design. WordPress and .htaccess are shared-password by design.

Rule of thumb:

• Client previews, staging for stakeholders, internal docs -> email whitelist.
• Wedding sites, paid-content gates, anything where you're handing out one string to a known group -> shared password.

If you're picking shared password by default just because it's the first thing every guide describes, you're choosing the harder long-term path.

How to password protect a website: 5 methods

All five work in some setting. Four of them fall short for the common case (one client preview, one pre-launch site, one wedding page) - either they ask for skills the user doesn't have, security guarantees they don't deliver, or both. Here they are in order of how much pain they cause.

1. Your host's built-in password feature (easiest)

This is the one-toggle path. The host checks the password before serving anything. Static site, dynamic site, doesn't matter - the protection lives at the edge. This is also the cleanest way to password protect a static site, because there's no server-side code to add.

• Hostsmith: built-in Private Sites on the Starter plan and up. Shared password or an email whitelist.
• Netlify password protect: site-wide passwords exist but live on a paid tier - check the current pricing page before assuming the free plan covers it.
• Vercel: deployment protection (Vercel Authentication or Password Protection) is a paid feature on Pro and above - again, worth confirming on their pricing page since the tiers shift.
• Squarespace: page-level passwords are baked in on most paid plans.
• Wix: has a "Members Only" mode if you want to password protect a Wix website with member accounts rather than a shared password.

If you don't have a host yet, the host an HTML file online walkthrough covers the basics. If you're shipping output from an AI builder, the Lovable deploy guide shows the same pattern end to end.

2. WordPress page passwords or a plugin - why this falls short for most readers

If you're already on WordPress, there's a free per-page password field in the publish panel. It's clunky, but it works for one or two pages.

For something more serious (member areas, multiple gates), plugins like Password Protected or Restrict Content do the heavy lifting. We won't deep-dive WordPress here because every other article on how to password protect a website already does. The shortfall: you have to be on WordPress in the first place. If you're not, spinning up a WordPress install just to gate a preview is the wrong amount of work.

3. .htaccess + .htpasswd on Apache - why this falls short for most readers

The original dev approach, and still the right answer if you control an Apache server. Drop two files into the site directory and Apache asks for a username and password before serving anything. No plugin, no third-party service, no DNS change. For a developer with shell access to a VPS already serving the site, the setup is short and adds zero new dependencies.

The .htaccess file:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /full/path/to/.htpasswd
Require valid-user

Generate the hashed password line on your machine:

htpasswd -c .htpasswd preview

That writes a .htpasswd file in your current directory containing one line like preview:$apr1$xj2..... - the username preview followed by the hash. The -c flag creates (and overwrites) the file, so use it once for the first user. To add a second user, drop the -c: htpasswd .htpasswd reviewer2. Adding a second user with -c would nuke the first.

Now move .htpasswd to the absolute path you used in AuthUserFile (keep it outside the web root so nobody can fetch it via HTTP). Reload Apache and the directory is gated.

Prereqs: an Apache server, SSH or FTP access, and the ability to edit hidden files. If those three are familiar, this works fine. If any of them are new, skip it - the modern host-built-in path is faster and harder to break.

Common gotcha: .htaccess is only read if the parent <Directory> block (in your main Apache config) has AllowOverride All or at least AllowOverride AuthConfig. On a default install this is sometimes off, and on shared hosting you often can't edit the main config to fix it. The silent failure is "the password prompt never appears and the site serves like normal." If that happens, that's the first thing to check - and if you're on shared hosting, the workaround is usually to switch to a host with a built-in toggle.

Nginx has its own equivalent (auth_basic with an auth_basic_user_file directive pointing at the same .htpasswd). Same idea, different config syntax - generate .htpasswd the same way, drop it on the server, point the directive at it, reload.

Two things .htaccess won't do: per-user revocation (everyone shares one password, so removing a viewer means rotating) and detailed access logs beyond standard web logs. If you need either, jump to Cloudflare Access.

4. Cloudflare Access (Zero Trust) - why this falls short for most readers

The "free enterprise" option. Cloudflare's free Zero Trust tier (up to 50 users at the time of writing - tier limits move, so check before you plan around it) lets you put a real identity provider in front of a site. Users sign in with Google, Microsoft, GitHub, a one-time email code, whatever you wire up. Per-user revocation, real access logs, no shared password to forward.

The setup, end to end:

1. Proxy DNS through Cloudflare. The site's domain has to be on Cloudflare's nameservers, and the relevant record has the orange cloud on (proxied, not DNS-only). If it's not proxied, Access can't see the traffic.
2. Sign in to the Zero Trust dashboard. It's a separate dashboard from the main Cloudflare site management - look for "Zero Trust" in the sidebar.
3. Access -> Applications -> Add a self-hosted application. "Self-hosted" is the right type for a public website you want to gate; tunnels and SaaS apps are different flows.
4. Set the application hostname and attach a policy. Hostname is the URL you want to protect (e.g., staging.example.com). The policy is where you list allowed emails, an allowed email domain (@yourcompany.com), or an identity provider you've connected.
5. Verify in a fresh private window. First hit to the protected URL should bounce to Cloudflare's auth screen - a private window matters here because a cached Cloudflare session in your normal browser will sail past the gate and trick you into thinking it's off.

It's excellent. It's also overkill for a wedding website, and it requires a Cloudflare account on the DNS path before anything serves. Use it when you actually need per-user logs and revocation; pick a host's built-in password for everything else.

5. JavaScript "password gates" - why this falls short for everyone

You will see tutorials that say: write JavaScript that prompts for a password, compare it to a string in your code, and window.location.href to the secret URL if it matches.

This is security theater. The "secret" URL, the password, and the comparison logic are all in the page source. Anyone who opens DevTools can read them in three seconds. Search engines can crawl the redirect target. Cached copies leak.

If you Google how to password protect a website html and land on one of these snippets, close the tab. Don't ship this. The password protect HTML page walkthrough covers the right way to gate a raw HTML file.

Compare the 5 ways to password protect a website

If you only want one method, pick the host's built-in toggle. Here's the full comparison:

GitHub Pages isn't in the table because it has no native password feature at all. If you're on GitHub Pages and need protection, you either move hosts (the GitHub Pages alternatives roundup and the dedicated GitHub Pages password protect walkthrough cover the two paths) or wrap it in Cloudflare Access. Vercel's paid-only password story is part of why the Vercel alternatives roundup and the Vercel password protection page exist too. Netlify's gate sits behind a paid tier too - see Netlify password protection.

How to password protect a static site, end to end

This is the path for the designer scenario most readers land here with. You have HTML files, maybe a folder of images, and you want a single password in front of the whole thing.

1. Upload the folder. Drag and drop works on most modern hosts - the drag-and-drop hosting walkthrough covers it if you've never done it.
2. On Hostsmith, you're on the Starter plan or higher. In the site settings, flip on Private Sites.
3. Pick the mode. Shared password is the "give clients one string" option. The email whitelist is the more interesting one - paste in a list of allowed emails and only those people can get in. No password to forward, no rotation when a project wraps, and you can remove a reviewer in one click instead of telling everyone the password changed. For client previews where the same handful of emails see every revision, the whitelist mode is usually the right default.
4. Grab the URL. On the shared hostsmith.link domain it'll look like your-site.us.hostsmith.link or your-site.eu.hostsmith.link (the region prefix is mandatory there). If you've hooked up a custom domain, the URL is whatever you set - no region prefix.
5. Send it.

If your "site" is actually a single PDF (proposals, lookbooks, contracts), the same protection model applies - more in the PDF hosting guide.

A quick aside on Google Drive: a Drive share link with "anyone with the link can view" is the obscured-not-protected example. Fine for a meme, not fine for unreleased client work - that's obscurity, not protection, and one forwarded email is all it takes. The Google Drive website hosting alternatives roundup covers this in depth.

How to password protect website content for free

"Free" almost always means "free if you already have the underlying thing." Three realistic free paths, with the catch on each:

• WordPress per-page passwords. Free if you already self-host WordPress. The page-password field is built into the publish panel. Free hosted WordPress.com plans don't include it.
• .htaccess on Apache (or auth_basic on Nginx). Free if you already pay for a server you control and have shell access. Not free if "free" means "no server at all."
• Cloudflare Access free tier. Up to 50 users at no cost (at the time of writing), but the site's DNS has to be on Cloudflare and proxied. If you're already on Cloudflare DNS, this is the strongest free option by a wide margin.

Managed static hosts - Netlify, Vercel, Hostsmith - all gate password protection behind paid tiers in 2026. Hostsmith Private Sites starts on the Starter plan, not the free plan. That's worth saying plainly so nobody arrives expecting otherwise.

If "free" means "no new paid plan," those three are the realistic paths. If "free" means "no infrastructure at all," there isn't one - somebody has to pay for the server checking the password.

Platform-specific walkthroughs

The methods above are general. If you've already committed to a specific platform, the focused walkthroughs cover the exact UI clicks, where each platform's password feature lives, and the fallback when the platform doesn't have one:

• Vercel password protection
• Netlify password protection
• Framer password protect page
• Webflow password protect page
• GitHub Pages password protect
• Password protect an HTML page

Best practices: passphrases and HTTPS

Two things are worth getting right no matter which method you pick.

Use a passphrase, not a "complicated" short password

Four random words beat a clever 8-character string with substitutions. correct-horse-battery-staple is dramatically harder to brute-force than P@ssw0rd1, and a human can actually remember it long enough to type it once. NIST's current password guidance (SP 800-63B) backs this up: length is what matters, mandatory composition rules and mandatory rotation are mostly cargo cult. For a client preview gate, generate four words from a wordlist and use them.

If the gate is the email-whitelist kind, there's no password to choose at all. That's part of why the whitelist mode is the better default for repeated viewers.

Don't ship a password without HTTPS

A password sent over plain HTTP is plaintext on the wire. Anyone on the same network can read it. Worth saying out loud because the failure mode is invisible: every managed host worth using - including Hostsmith - ships HTTPS by default. If you're rolling your own server with .htaccess, get a Let's Encrypt cert installed and a redirect from http:// to https:// before you turn the password on. Otherwise the password is theater.

When a password isn't enough

Password protection covers maybe 90% of the situations people ask about. The other 10%:

• You need per-user access logs and revocation. Who viewed the preview, when, and the ability to kick someone out without rotating the password for everyone. Use an identity provider (Cloudflare Access, Google Workspace SSO, Auth0).
• You're handling regulated data. HIPAA, SOC 2, PCI - a static site behind a password is not your answer. You need a real app with audit trails and an actual compliance posture.
• You want to stop downloads or screenshots. You can't. A password gets you in or out. Once a viewer is in, they can save, screenshot, screen-record, or just point a phone camera at the monitor. DRM is a much bigger conversation and "I added a password" is not the start of it.

Most client previews and pre-launch sites aren't any of those - a password is exactly right.

Password protection and SEO

Will Google index a password-protected site?

No. Googlebot is just another HTTP client - it hits the URL, gets the auth challenge, can't supply credentials, and gives up. There's nothing to index because there's nothing it can fetch. For a client preview, a staging site, or anything pre-launch, that's exactly what you want: the site stays out of search results until you turn protection off at launch.

One nuance worth knowing. If the URL itself has been linked from other indexed pages, the URL can appear in Google's index as a "no content" result - just the link, no title or snippet, because Google couldn't see the page. That's harmless for almost everyone, but if it bothers you, add a noindex directive at the server level (not in HTML, which Google won't see) or block crawlers in robots.txt.

The reverse case is the real failure mode: an obscured URL with no auth at all. That can absolutely end up indexed if anyone links to it from a public page, a public Notion doc, or a tweet. Obscurity isn't an SEO strategy any more than it's a security strategy.

If you ever do want the site indexed, just turn protection off at launch. Google will crawl it on its normal cadence, no extra step needed.

FAQ

Can I password-protect a single HTML page? Yes. Most managed hosts apply protection at the site level (the whole upload is gated), but WordPress and Squarespace let you password individual pages. If you only want one page protected, the simplest path is to upload just that page as its own static site and gate the whole thing.

Is JavaScript password protection secure? No. The password is visible in the page source. It's a speed bump, not a lock. Treat it as zero protection.

How do I password protect a wedding website? The same way as anything else - paid plan on Squarespace, Wix Members Only, or upload a static site to a host with built-in protection. Whatever you do, don't put the password in the email and tell guests to "forward freely." That's the obscured-not-protected trap with a bow on it.

What's the difference between password protection and a private link? A private link is just a URL nobody else has guessed yet. Password protection is the server checking credentials before sending the page. Private links leak through bookmarks, shared screens, browser history sync, and forwarded emails. Passwords don't.

Shared password or email whitelist - which one should I pick? For anything with repeat viewers (client revisions, staging reviewed by a fixed team), email whitelist. For one-shot broadcasts to a known group (a wedding site, a paid guide), shared password. The whitelist mode trades two seconds of setup (pasting the list) for not having to rotate when somebody leaves the project.

Can I password protect a website on Vercel or Netlify for free? No. Both put the site-wide password gate behind a paid plan. The dedicated walkthroughs - Vercel password protection and Netlify password protection - cover the cheaper paths if upgrading just for the gate doesn't pencil.

Most readers picked the right method by paragraph three: the host's built-in toggle. The other four sections exist because four sections of competitor articles do, not because most readers actually need them. The afternoon spent debugging .htaccess for a site three clients will look at once is the cost of treating "more options" as "better answer."

If you're sending a preview to humans, paste the emails into your host's whitelist, ship the URL, and move on. The other methods cover real edge cases - just not yours.