# 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. ## Plan availability Password protection starts on Starter. - **Free:** not included - **Starter:** included - **Pro:** included - **Business:** included - **Enterprise:** included ## 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 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. ## 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. ## Doing this without us The two usual substitutes both look like protection, and one of them is not. - **When the check happens.** Droply: Before the response is written. A JavaScript password in the page: After the file has already been downloaded. - **Images, PDFs and other assets.** Droply: Covered by the same gate. A JavaScript password in the page: Not covered. A direct link opens them. - **Reading the password out of the source.** Droply: Not possible; it is stored hashed on our side. A JavaScript password in the page: Usually one click in view-source. - **Guessing attempts.** Droply: Locked after a handful of wrong tries. A JavaScript password in the page: Unlimited and invisible. - **What the visitor has to do.** Droply: Type a password once. A JavaScript password in the page: 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. ## Related features - [Expiring links](https://droply.host/features/expiring-links) - [Custom domains](https://droply.host/features/custom-domains) - [Version rollback](https://droply.host/features/version-rollback)