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 12 October 2026. Plans change — check the vendor's page before you rely on this.

Read the two Netlify rows together. They give the same answer — a shared password is a Pro feature — and differ only on where it lives: under Password Protection on the older plans, under Project visibility on the credit-based ones. On credit-based Free and Personal, Project visibility offers Private instead, which is a sign-in for your own team, not a password you can hand a client.

miinideck. A shared password is free, with or without an 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 can take a password as well, but you can't change it afterwards, 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 your Netlify account is on a Pro plan, the shared password is already there. On a credit-based Pro plan it's under Project visibility, not Password Protection. On Free or Personal it isn't on either plan family.

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 on the upload that needs no account the password can't be changed later.

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.