A proposal with negotiated pricing is written for a few people, but a link goes wherever it is pasted. Chip Bellfort, who runs sales at Synergetics, would like his champion to read the discount before the champion's procurement team does. Password-protected links put a check between the URL and the page. The link opens anywhere, and the content arrives only after someone types the right password.
What a password does to a link
HTMLvault checks the password on the server. When someone opens a protected URL, HTMLvault sends a password gate instead of your page, and the HTML stays on the server until the typed password matches. Until then, the page source contains the gate and none of your content.
The version people build by accident checks the password in the browser: a JavaScript prompt in the page, a CSS overlay, or a section hidden until the right word is typed. Each one sits on top of content the browser has already downloaded. Anyone can view the source, turn off scripts or delete the overlay and read the whole page. A browser-side prompt protects nothing.
If you or an AI tool are generating a page for HTMLvault, do not write a password prompt, overlay or hidden section into the HTML. Publish the page as it should be read and set the password on the link.
A password has nothing to do with search, because every HTMLvault link is noindex whether it has a password or not. The password is for people who end up holding the URL but were never meant to see the content. They might get it from a forwarded email, a link pasted into the wrong channel or the browser history on a shared laptop.
Add, change or remove a password
Passwords are available on Pro, Teams and Enterprise. You set them per link on the web, either on the upload form when you create the link or from the links dashboard afterwards. MCP and the REST API cannot set a password. If your AI tool published a page through either one, add the password on the web before you send the URL to anyone.
To add a password when you create a link:
- Below the HTML content editor, find the Password dropdown in the options grid, next to Expires in, Domain and Tracking.
- Choose New. A Set password field appears under the grid.
- Type the password. Once the field has text, an icon at its right edge shows the password as plain text. After that, the same icon copies it so you can paste it into a separate message.
- Click Create link. The button stays disabled while New is selected and the field is empty.
To change or remove a password, open the link for editing. The dropdown defaults to Keep current. New replaces the password, and Remove appears only when the link already has one. A new password ends every earlier unlock, so anyone who opened the page with the old one is asked again. The URL stays the same either way. The dropdown is disabled while the HTML editor is open, so close the editor first.
On Free, the dropdown shows New (Pro), which leads to the upgrade page. On Teams and Enterprise, adding or removing a password re-runs your workspace's publishing rules. Those rules can treat password-protected and public pages differently, so removing a password can change whether a page passes.
What the reader sees
A recipient who opens a password-protected link sees the gate, which has a password field and nothing from your page. The right password unlocks the page in that browser for up to a day. After that, or on another device, they have to enter it again.
Someone who has the link but not the password can click Ask for password on the gate, which emails you. You decide whether to answer. A request you did not expect tells you the link has reached someone you did not send it to.
When the link is pasted into Slack, an email or a social post, the preview card says the page is protected and shows nothing from it, so no title, description or image from your page appears. A deal name in your page's <title> stays out of the channel preview.
Views, unique and repeat viewers, scroll depth and time on page still show up in per-link analytics, so you can see when the proposal was read and how far down the reader got.
When to use one
A password fits when the group is small, the time is limited and the content would cost you something if it traveled. Examples include a proposal with pricing for a buying committee, a campaign page shared with an agency before launch and an internal preview that should stay inside the team. Nobody needs an account, and the only extra step for the reader is one field.
Here is a worked example for a proposal with pricing:
- Generate the proposal in Claude and publish it through MCP with
create_linkand a 30-day expiry, so the page closes after the decision window. - Before you send the URL anywhere, open the link from the links dashboard, choose New under Password and set a password. Don't use the client's name, the quarter or the word "proposal". A random three-word phrase is hard to guess and easy to read out on a call. If you upload on the web instead, set the password on the upload card when you create the link.
- Email the link, and send the password another way: a text message, a direct message, or out loud on the call where you walk through the pricing. If both go in one email, a single forward hands over both.
- Watch the link's analytics. A repeat visit from a new city the next day usually means the champion is sharing it internally.
- If the price changes, edit the page in place. The URL the buyer has stays the same.
- If the buying group changes and someone should no longer get in, set a new password. That ends every earlier unlock, so send the new password to the people who still need it.
Where a password falls short
A password controls who can open the page. It does not control what happens after that, and it does not know who typed it.
- It travels with the link. Whoever has both has the page, and the two often end up in the same thread. Sending them separately only helps until someone forwards both.
- It can be forwarded. The recipient you meant to have it can pass it on, usually with good intentions and a generous idea of who counts as internal.
- A screenshot ignores it. Once the page is open, nothing stops a capture, a print or a copy-paste into another document.
- It proves who knew it, not who someone is. Five people sharing one password show up as five browsers, not five names, so analytics on a shared password report activity, never identity.
- You cannot withdraw it from one person. Changing it ends access for everyone, and you have to resend it to the people who still need it.
- It does not read the page. An API key or a customer list in the HTML is still there behind the gate. Every publish is checked for secrets and personal data anyway, by pattern matching that uses no AI tokens. How to scan HTML for API keys before sharing explains what that check catches.
When it is the wrong control
Choose the control based on what you need to know or prevent.
You need to know who read it. Use one link per recipient. create_recipient_links makes a separate tracked link for each person from one page, and each person's views land on their own link. That only tells you whose link was opened, not who was at the keyboard. Still, it is more than a shared password can tell you.
The page should stop working soon. Use a short expiry. A draft review that only matters until Friday needs an expiry of 3 or 7 days more than it needs a password, and once it expires the link stops opening the page. You can extend an expiry after sending if the deal slips. Link expiry settings covers how to choose the window.
The content should not be on a link at all. Don't publish it. Some content belongs in the system it came from: regulated records, anything where an audit trail must show which authorized person viewed it, and anything you could not accept leaking even behind a gate. A password cannot fix a recipient list that was too broad.
SSO does not fill this gap either. SSO/SAML (included on Enterprise, an add-on on Teams) controls who signs in to HTMLvault and never restricts who can view a link. Signing in uses one-time email codes, passkeys, Google or Apple, so the only password in this workflow is the one on the link. SAML SSO for sharing tools explains what SSO does cover.
For a pricing proposal going to a small buying group, a password is the right control. A forwarded thread reaches a gate that shows nothing. If the link goes further than you meant, one new password closes it for everyone at once.