Can you password-protect a page on a free plan?

A client looks at the page you built and says the obvious thing: this shouldn't be something anyone can just open. Fair. You go into your host's settings, find Password Protection, click it — and instead of a field to type a password into, you get a plan comparison with Pro highlighted.

So the question isn't really how a password works. It's narrower and more annoying than that: is this switch on anyone's free plan, and if it isn't on yours, what do you do about it today?

Which free plans let you password-protect a page?

These are the four hosts this question usually comes up on. Everything in this section can change, which is why it all sits in one table with a date under it. The rest of the piece is about what the rows mean.

Checked against each vendor's own documentation on 17 September 2026. Plans change — check the vendor's page before you rely on this.

Read the two Netlify rows twice, because they describe the same product and give opposite answers. On the older plans, a password for the whole site is a Pro feature. On the newer credit-based plans, a shared password is there on Free too — but the docs send you to Project visibility, "instead of from Password Protection settings". If you went looking under Password Protection, you were looking where the older plans keep it. Which family your account is on decides which screen you get.

miinideck. A shared password comes with the free account: it's a field on the upload form and a setting on every page in the dashboard, and there is no plan check in front of it. It covers the page it's set on, and for a zipped build, every file inside it — those are only served once the page has been unlocked. The upload you can do without signing in has no password option at all, because there's no account for the setting to belong to; signing in is free. And a password-protected page can't also be made searchable. One exists to be read by search engines and the other exists to stop exactly that, so they're mutually exclusive.

Does password protection cover the live site, or just previews?

This is the part that decides whether you've actually solved the client's problem. Three different things get called "password protection", and they lock different doors.

A shared password on the site. One secret. You send it alongside the link; whoever has both gets in, and nobody needs an account anywhere. Netlify's older Pro plans describe it for "your entire site", and its credit-based plans let you apply it to "Production and previews". This is the lock a client can get through with nothing but your email.

A lock on previews. Preview deployments are the extra addresses a host makes for work that isn't live yet. Netlify's credit-based "Previews only" option sits here, and so does the Cloudflare preview guidance in the table. It's a good way to keep drafts away from people, but notice what it leaves alone: Cloudflare's docs say your custom domains and <project>.pages.dev "will not be affected". If what your client is going to open is the live site, a preview lock isn't standing in front of it.

A sign-in gate. It doesn't ask for a password; it asks who you are. Cloudflare Access limits viewing to your Cloudflare account. Private GitHub Pages limit it to people with read access to the repository. That's real control over who, one person at a time, and it's the right tool for a team whose members already have accounts. For a client it means they need an account on your platform and you need to grant it — and a person opening one link from one email is exactly who that trips up.

So before you pay for anything, answer this: who is on the other side of the lock, and what do they already have? A colleague with an account on your team is better served by a sign-in gate than by any password. A client with nothing but your email needs a shared password on the address they'll actually open — the production one, not a preview.

How do I password-protect a page without paying for Pro?

Four routes, roughly in order of how little they ask of you.

1. Check which plan you're on. If you're on Netlify and your account is on a credit-based plan, the docs say the shared password is already on your plan — under Project visibility. That's the cheapest fix there is.

2. Encrypt the page itself. Client-side encryption tools such as StatiCrypt turn your HTML into a file that decrypts in the reader's browser once they type the password. The host doesn't have to do anything, so it works on any free plan. The limit is structural: the encrypted contents reach the reader's machine before they type anything, so the passphrase is the whole wall. That's fine against forwarding and people stumbling onto the page, and weaker when the contents genuinely can't leave. It also has to be redone every time the page changes. Password-protecting a static page without a server sets this next to a hosted gate, and if encryption is your route, our password-protect tool does that step for you.

3. Put the one page that needs a lock where the lock is free. Very often it isn't the whole site the client is worried about. It's one page — a proposal, a pricing sheet, a staging copy of a landing page. A private-link host takes that single page (or a zipped build), gives it an unguessable, no-index address, and lets you put a shared password on it. On miinideck that's on the free account: the page is held back on the server until the password checks out, and repeated wrong guesses get throttled. Password-protect a webpage is the short version of how that works. Two free-plan limits worth knowing before you send it: links expire after 7 days unless it's your one always-on link, and the upload that needs no account has no password option.

4. A sign-in gate, if everyone already has an account. For an internal team, the identity-based locks in the table — Cloudflare Access, private GitHub Pages — are the better tool, for the reasons above. What they cost is on their own pages; it isn't covered here.

(If you were about to try .htaccess: it's a configuration file for the Apache web server, and a static host doesn't hand you an Apache to configure. It will usually upload fine and do nothing.)

Should I upgrade, or move the page somewhere else?

If what needs protecting is a production site that already lives on the platform — a custom domain pointing at it, a deploy on every push, previews your team relies on — then the lock you're looking at is attached to all of that. Getting a free password somewhere else means moving the domain, the pipeline and every link you've already sent, to save the cost of one setting. In that case paying for the lock is often the smaller bill. It's also the one you can read off a pricing page, where the cost of moving is an afternoon you haven't priced yet.

If what needs a lock is one page — a draft for a client, a report, a one-off preview — the sum comes out the other way. The platform's lock is built for a site, and you'd be buying site-shaped protection for a single page. Encrypting the file, or putting that one page on a private link, is the shorter path, and the site stays exactly where it is.

The mistake is treating it as one decision. The site and the page that needs the lock don't have to live in the same place.

What a shared password won't do

It's one secret held by everyone you give it to, and anyone can pass it on along with the link. If you need to shut one person out without changing it for everybody, that's the sign-in kind of lock, not a stronger password.

It also doesn't answer the wider free-tier question. For the field as a whole — a dozen hosts, public and private — the free HTML hosting comparison is the map. For what our own free limits mean in practice, including the 7-day clock and the one always-on link, when free HTML hosting stops being free walks through them.