How to Password Protect a Website (Without a Developer)

A designer I've done freelance work with wanted to send a tiny portfolio site to two clients - and only those two clients - before going public. She paid for a Squarespace plan, gave up, then asked me what dev people do. I gave her four options. Three were overkill. One was a single toggle.

That conversation is basically this whole article. If you need to password protect a website and you don't want to learn Apache, here's the field guide I wish I had.

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 you'd want this in the first place

The five real situations I see 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.

How to password protect a website: 5 methods

I've used all of these. Some I love. One I beg you not to use. When people search how to password protect website content for a small audience, these are the five real answers - in order of how much pain they cause you.

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 access protection on the Standard plan and up. Shared password or Google sign-in.
• 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, my host an HTML file online walkthrough covers the basics.

2. WordPress page passwords or a plugin

If you're already on WordPress, you have 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. I won't deep-dive WordPress here because every other article on how to password protect a website already does. Google it and you'll find dozens of step-by-step tutorials before lunch.

3. .htaccess + .htpasswd on Apache (classic dev method)

The original dev approach. You drop two files into your site directory and Apache asks for a username and password before serving anything.

.htaccess:

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

.htpasswd (generate the hashed line with htpasswd -c .htpasswd raj on your machine):

raj:$apr1$xj2.....

Prereqs: an Apache server, SSH or FTP access, and the ability to edit hidden files. If you nodded along to all three, this works fine. If any of those words were new, skip it.

Nginx has its own equivalent (auth_basic), same idea.

4. Cloudflare Access (Zero Trust)

The "free enterprise" option. Cloudflare's free Zero Trust tier 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.

For a normal public site, the setup is: proxy the site's DNS through Cloudflare, create an Access application pointing at the hostname, and attach a policy (allowed emails, domain, identity provider). No tunnel needed - tunnels are for hiding a private origin, which isn't what most readers here are doing.

It's excellent. It's also overkill for a wedding website. I've used it when a client needed audit logs for who viewed a preview and the ability to revoke a single reviewer without rotating anything.

Use it when you actually need per-user logs and revocation.

5. JavaScript "password gates" - just don't

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 your 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. Please don't ship this.

Compare the five methods

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 or wrap it in Cloudflare Access. I dug into the move-hosts angle in my GitHub Pages alternatives roundup, and Vercel's paid-only password story is part of why I wrote about Vercel alternatives too.

How to password protect a static site in under two minutes

This is the path for the designer scenario above. 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 - here's my drag-and-drop hosting walkthrough if you've never done it.
2. On Hostsmith, you're on the Standard plan or higher. In the site settings, flip on access protection.
3. Pick the mode. Shared password is the "give clients one string" option. Google sign-in is the more interesting one - you 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 five emails see every revision, this is the mode I default to.
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 my 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. I wrote a longer piece on Google Drive website hosting alternatives if you want the full picture.

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.

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 website for free? Three real options: WordPress page passwords (free if you already self-host WordPress), .htaccess on a server you already pay for, or Cloudflare Access on its free Zero Trust tier. Most static hosts (Netlify, Vercel, Hostsmith) put password protection on a paid plan - check each provider's current pricing page since the tiers move around.

Can search engines still index a password-protected site? No. Googlebot can't get past the password, so the site stays out of the index. That's a feature, not a bug, for client previews and pre-launch work. If you want it indexed later, just turn protection off when you launch.

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.

Here's the contrarian take to close on: most people overthink this. They read the same SEO-bait listicle on how to password protect a website, see seven methods, and pick the most complicated one because it feels serious. Then they spend an afternoon debugging .htaccess for a site three clients will look at once.

If you're sending a preview to humans, a shared password on a managed host is the right answer. Pick a plan, ship the preview, move on. The other methods exist for real reasons - just not yours.