How to Password Protect a Netlify Site: Basic Auth (Free) and Pro Methods

Netlify deploys are public by default. That means anyone with the URL — including search engines — can see your work in progress. This becomes a problem fast:

• Google indexes your half-finished staging site
• Someone forwards a deploy preview link to the wrong Slack channel
• A client sees a broken layout before you've had your morning coffee

There are actually five different ways to lock things down on Netlify, and which one you should use depends on your plan and what you're trying to protect.

The five methods, compared

| Method | Works on Free plan? | Best for | |---|---|---| | Basic Auth (_headers file) | Yes | Quick staging protection, per-path rules | | Password protection (dashboard) | Pro and above | Client previews, non-technical reviewers | | Team login protection | Enterprise only | Internal team access | | SSO protection | Enterprise only | Corporate authentication | | Role-based access (JWT) | Varies | Granular per-page access control |

Most people just need one of the first two. Let's start with the free option.

Basic Auth with a _headers file (free)

This works on every Netlify plan. You drop a _headers file into your publish directory and add Basic Auth credentials. It's not fancy — visitors get the browser's default username/password prompt — but it gets the job done.

Protect the whole site

/*
  Basic-Auth: demo:letmein

That's it. Username demo, password letmein, every page.

Protect specific paths

Want to lock down /admin and /staging but keep the rest public?

/admin/*
  Basic-Auth: admin:secretpassword

/staging/*
  Basic-Auth: tester:preview123

Give different people different passwords

This is something the dashboard password protection can't do. With Basic Auth, you can set multiple credentials for the same path:

/*
  Basic-Auth: alice:password1
  Basic-Auth: bob:password2

Handy when you want to know who's accessing what, or when you need to revoke one person's access without changing everyone else's password.

Where does the _headers file go?

It needs to end up in your publish directory — the folder Netlify actually serves:

| Framework | Put it in | |---|---| | Plain HTML | Root folder | | Next.js | public/ | | Gatsby | static/ | | Hugo | static/ | | Astro | public/ | | SvelteKit | static/ |

Netlify picks it up automatically during deployment.

The downsides

I'll be honest — Basic Auth has some rough edges:

• The browser remembers credentials until you close it (there's no real "logout")
• The login prompt looks like it's from 1998
• Credentials sit in plain text in the _headers file
• There's no "forgot password" flow

For protecting a staging site from Google's crawlers? Totally fine. For showing clients a polished preview experience? Use the dashboard method instead.

Dashboard password protection (Pro plan and up)

If you're on a Pro plan or higher, Netlify has built-in password protection that looks much nicer. Instead of the browser's basic auth popup, visitors see a styled password page.

Setting it up

1. Go to Project configuration > Access & security > Visitor access > Password Protection
2. Pick Basic password protection
3. Enter a shared password
4. Choose the scope:
   • All deploys — covers production, deploy previews, and branch deploys
   • Non-production deploys only — keeps production public, protects everything else (Enterprise only)
5. Save

Everyone uses the same password. It's simple, which is exactly what you want when a client just needs to click a link and type a password.

Team login and SSO (Enterprise)

If you're on an Enterprise plan, you get two more options:

Team login protection — visitors need to log in with their Netlify team account. This is better than shared passwords because you can revoke access per person, and there's an audit trail. Only Developers, Team Owners, and Billing Admins get access though — Git Contributors can't.

SSO protection — hooks into your company's SAML SSO. Auth tokens expire after 1 hour of inactivity. If your security team requires SSO for everything, this is the way.

Protecting deploy previews specifically

This is the most common scenario. A teammate posts a preview link in Slack, and suddenly your half-built feature is visible to the whole company.

On Pro: turn on dashboard password protection scoped to "All deploys."

On Enterprise: use "Non-production deploys only" to protect previews while keeping production public.

On Free: add Basic Auth to your _headers file. The catch is it protects everything, including production. If you need production to be public while previews are locked down, you'd have to conditionally include the _headers file based on the deploy context — doable with a build script, but kind of a pain.

Team-level defaults

If you manage multiple sites, you can set a default protection level for the whole team:

1. Team settings > Access & security > Visitor access
2. Set Default Password Protection settings

Every new site inherits these settings. Individual sites can still override them.

Which one should you use?

• Free plan staging protection → Basic Auth in _headers
• Client previews that need to look professional → Dashboard password (Pro)
• Internal company tool → Team login (Enterprise)
• Multiple people, different access levels → Basic Auth with multiple credentials, or JWT-based role access
• Corporate SSO requirement → SSO protection (Enterprise)