PASSWORD PROTECTION

Password protect a page you published

Set one password on a site and nothing behind it is served until a visitor enters it. The check happens at the edge, before any file leaves the server.

Free plan, free SSL, no credit card.

Plan availability

Which plans include password protection

Password protection starts on Starter.

  • Free Not included
  • Starter Included
  • Pro Included
  • Business Included
  • Enterprise Included

Read from the plan records this account is billed against, not from a page someone wrote, so it cannot disagree with what happens when you click the button. See every plan and its limits.

What it does

A door in front of the files, not a notice on the page

The password is checked by the server that would otherwise hand over the bytes. If it has not been entered, there are no bytes to hand over.

Turn it on for a site and every request to that site meets a prompt first: the page, its stylesheet, its images, a PDF sitting in a subfolder, all of it. Once a visitor gets the password right, their browser holds a cookie for that site and the rest of the visit is normal. There are no accounts to create, no invitations to send and nothing for the visitor to sign up for, which matters when the person you are sending it to is a client rather than a colleague.

The distinction worth understanding is between this and a password written into the page itself. A JavaScript prompt in an HTML file is decoration: the file has already been downloaded by the time it runs, so anyone who opens the source can read what it was hiding, and the assets around it were never protected at all. Here the check happens before the response is written, so a direct link to an asset is refused the same way the page is. Wrong guesses from one visitor are locked out after a handful of tries, which is what actually stops someone working through a list.

How to use it

Three steps

  1. Publish the site

    Upload as normal and check the page works. Protection is a setting on the site, not something baked into the files.

  2. Set a password

    Open the site in the dashboard and set one. It is stored hashed, so nobody, including us, reads it back out later.

  3. Send the link and the password separately

    Two channels beat one. The link is safe to put in a calendar invite; the password is not.

Where it earns its keep

When people reach for this

A build a client is reviewing before launch

Work in progress should not turn up in a search result or get forwarded past the person who asked for it. Client website preview is this exact workflow, written out.

A document meant for one recipient

A quote, a proposal or a contract shared as a PDF on a link is easier to send than an attachment and easier to withdraw afterwards.

An internal page you would rather not publish openly

A runbook, a price sheet or an event brief that needs to be reachable from a phone, without becoming public. Pair it with an expiry date if it is only relevant for a week.

The alternative

Doing this without us

The two usual substitutes both look like protection, and one of them is not.

  Droply A JavaScript password in the page
When the check happens Before the response is written. After the file has already been downloaded.
Images, PDFs and other assets Covered by the same gate. Not covered. A direct link opens them.
Reading the password out of the source Not possible; it is stored hashed on our side. Usually one click in view-source.
Guessing attempts Locked after a handful of wrong tries. Unlimited and invisible.
What the visitor has to do Type a password once. Type a password once, with none of the above.

Compared against the client-side password snippets commonly recommended for static sites. Checked September 2026.

When this is not the right tool

This is one shared password for one site. It is deliberately not an access control system.

  • There is one password per site, not one per visitor, so you cannot tell two recipients apart or revoke one of them.
  • There are no user accounts, roles or per-page permissions for visitors.
  • Anyone who has the password can pass it on. If that is a real risk, add an expiry so the window is short.
  • It protects a site hosted here. It cannot put a gate in front of a page hosted somewhere else.

Frequently asked questions

Which plan includes password protection?
It starts on Starter. Sites on plans below it are public, and free sites are additionally served with a noindex header so they do not appear in search results.
Are the images and PDFs protected too?
Yes. The check runs before any file is served, so a direct link to an asset inside a protected site is refused exactly like the page is.
Do my visitors need an account?
No. They type one password and nothing else. There is no sign-up, no email verification and no account for them to manage.
Can I use a different password per person?
No. There is one password per site. If you need to tell recipients apart, publish separate sites, or use an expiry so the shared password stops working on a date.
Can somebody read the password from the page source?
No. It never reaches the browser. It is stored as a hash on our side and compared server-side, which is the difference between this and a script in your HTML.
What stops someone guessing it?
Repeated wrong answers from the same network are refused after a small number of attempts, before the comparison even runs, so working through a word list is not practical.

Keep exploring