# How to password-protect an HTML page or shared link · Stacktree

Source: https://stacktr.ee/password-protect-html-page

[Skip to content](#main)   [stacktr.ee](/)  [Examples](/#proof) [How it works](/#how) [Pricing](/pricing) [Security](/security) [Log in](https://app.stacktr.ee) [Publish one](https://app.stacktr.ee/?join=1)     By [Steve Smith](/about) · Founder, Stacktree Last updated September 20, 2026          how to

#  Password-protect an HTML page, with a passcode on a private link.

   Publish the page, set a password, share the link.  Only people with the passcode can open it, and the link is unguessable to begin with. Works for a client report, a proposal, or a Claude or Codex artifact you want to share outside its walls. Free covers 3 passcoded pages.

  [ See a protected page (passcode: demo) ](https://example-locked-review.stacktr.ee/)   [ Protect your own page free ](https://app.stacktr.ee/?join=1&from=seo_password_protect_html_page)  A live gated example. Type demo at the gate, exactly as your client would.

##  How do you password-protect an HTML page?

Publish it to Stacktree and set a password. Anyone opening the link is asked for the passcode before the page renders; the password is stored as a hash, never in plaintext, and it sits on top of an already-unguessable URL. You can set it in the dashboard, at upload, or with `set_password` over MCP, and add, change, or remove it later without the link changing. Passcodes work on every plan, free pages included.

## Why a password, when the URL is already unguessable

 A Stacktree link is private by default: it lives at a token URL with roughly 128 bits of entropy, is never listed or indexed, and is served with crawler-blocking headers. If you never share the link, nobody finds the page. So why add a password at all?

 Because links travel. A URL that is private the moment you create it can still be forwarded, pasted into a shared channel, or left in a browser history on a borrowed machine. A passcode is the second factor for exactly those cases: it means holding the link is not enough, the viewer also has to know a secret you set. For a client deliverable, a quote, an internal report, or anything you would not want opened by whoever the link reaches next, that second layer is the difference between "hard to find" and "needs permission."

## Every way to password-protect a single HTML page, honestly

 The question usually arrives as "I have one HTML file, how do I put a password on it?", and there are three real answers. Which one fits depends on whether you run a server and how much control you want after you share the page.

  - Basic auth on a server you run. If Apache serves the page, a .htaccess file with an AuthType Basic block, scoped to the one file with a <Files> directive and pointed at an .htpasswd file, does the job; nginx does the same with auth_basic in a location block. It is free and battle-tested. The costs: you need the server, credentials travel with every request so HTTPS is mandatory, the viewer gets the browser's grey credential dialog rather than anything branded, and there is no view count, no expiry, and no way to know the page was ever opened.
 - Static-host tricks. On hosts that only serve files, the options thin out. A JavaScript prompt that hides the content protects nothing, because the content still ships to the browser and view-source shows it. Client-side encryption in the StatiCrypt style is genuine protection, but every edit means re-encrypting and re-uploading, losing the password means losing the page, and revoking access means rotating the password with everyone who still needs in. The hosts' own gates are real but conditional: password protection sits on paid tiers at Netlify and Vercel, Cloudflare Pages routes you through an access-management product with its own login flow, and GitHub Pages simply has no option at all.
 - A hosted page with a passcode. Publish the file to a host where the password is a setting rather than a project: the link is unguessable before the password even applies, the gate is a branded page rather than a browser dialog, and you can rotate or remove the passcode, set an expiry, or swap the content without the URL changing. On Stacktree this works on every plan, including all 3 free pages and anonymous publishes. The rest of this page covers that route.

## How to set it

  - In the dashboard. Open the site, set a password, done. The page now prompts for it before rendering.
 - At publish time. Include a password when you upload the file, so the page is protected from its first second.
 - From an agent, over MCP. Call set_password with the password (or null to clear it). The same agent that published the page can lock it, so the whole flow stays in one place.
  However you set it, the password is hashed before storage, so Stacktree never holds the plaintext. Removing or rotating it is a one-line change and never moves the URL. On the other side of the gate, the viewer types the passcode once and reads: [no account, no app, nothing to install](/client-view-without-account).

## What it costs

 Passcodes are on every plan. The free plan puts one on any of its 3 pages, so you can see the whole flow (publish, lock, hand over the passcode) without paying anything. Solo, $19 a month, makes it a working tool: unlimited passcodes and email-domain gates, 25 pages live at a time that never expire, one custom domain, and no Stacktree badge on the page. Studio, $79, adds ten domains and the engagement view. Prices are flat per workspace and clients are never seats, so the people opening your pages cost nothing.

 The free plan's limits are elsewhere: 3 pages in total, each expiring after 7 days. The lock itself is never the paywall. Full detail on [pricing](/pricing).

## Password-protecting a Claude or Codex artifact

 This is the most common reason people reach for it, and the tools themselves do not cover it. A [Claude.ai artifact](/share-claude-artifacts) can be made public, but there is no passcode option, so "shared" means "anyone with the link." [Claude Code artifacts](/blog/artifacts-in-claude-code-explained) and [Codex Sites](/openai-codex-sites-alternative) are the opposite, locked to your organization with no password and no external viewer at all.

 Hosting closes the gap. Export the artifact to a self-contained HTML file, or have your agent publish it directly, put it on Stacktree, and set a password. Now you can hand a client or a contractor a link plus a passcode, with no Claude or OpenAI seat required to open it, and on your own domain from Solo up. The page is the same self-contained HTML the artifact already was; you have just added the lock the source tool left out.

## Layer it: password, email gate, expiry, burn

 A password is one option in a small set you can combine to match the sensitivity of what you are sharing:

  - Password for a shared secret with a person or small group. Every plan, Free and anonymous included.
 - Email-domain gate for a company audience, where viewers verify a work address by magic link. Mutually exclusive with a password on a single page, and also from Solo up.
 - Expiry from minutes to never, so a link does not outlive its purpose. Free pages are capped at 7 days; paid pages can be set to any length or to never.
 - Burn after read for a one-time view that deletes itself once opened. Pairing it with a password is the strongest use of the passcode gate: the gate runs before the burn claim, so a link preview or an email scanner cannot spend the single view. See [one-time view links](/one-time-view-links).
 - End-to-end encryption for the most sensitive pages, where the key lives only in the URL fragment and Stacktree stores ciphertext it cannot read.
  A passcode plus a short expiry covers most "share this carefully" situations without any of it being complicated.

FAQ

## Frequent questions

     How do I password-protect an HTML page? +  Publish the page to Stacktree and set a password on it, either in the dashboard, at upload time, or with the set_password tool over MCP. After that, anyone opening the link is asked for the password before the page renders. The password is stored as a hash, never in plaintext, and it sits on top of the unguessable URL the page already has. Passcodes work on every plan: all 3 free-plan pages can carry one, and Solo at $19 a month makes pages permanent with unlimited passcodes.   Do I need a paid plan to set a password? +  No. Passcodes work on every plan, including all 3 pages on the free plan and even anonymous publishes. What Solo at $19 a month adds is permanence and scale: 25 pages at a time that never expire, unlimited passcodes, email-domain gates, one custom domain, and no Stacktree badge on the page. Free pages expire after 7 days.   Can you password-protect a Claude or Codex artifact? +  Yes, by hosting the artifact rather than relying on the source tool. Claude.ai artifacts can be made public but have no built-in passcode, and Claude Code and Codex artifacts are org-only with no password option at all. Export the artifact to a self-contained HTML file (or have your agent publish it directly), put it on Stacktree, and set a password. Now anyone with the link and the password can open it, with no Claude or OpenAI account needed.   Is the link still private if I do not set a password? +  Yes. Every Stacktree page already lives at an unguessable token URL (roughly 128 bits of entropy) that is never listed or indexed, so the URL itself is the credential. A password is a second layer for when the link might be forwarded or pasted somewhere you do not control, or when a viewer should prove they know a shared secret, not just hold the link.   Password or email-domain gate, which should I use? +  A password is the simplest: one shared secret, good for a client or a small group. An email-domain gate is stronger for a company audience, it requires viewers to verify an address on a domain you choose (for example @yourco.com) by magic link. The two are mutually exclusive on a single page; pick the one that matches who should get in.   Can I add a password to a page I already published? +  Yes. The password is a setting on the site, not something baked in at upload, so you can add, change, or remove it at any time from the dashboard or with set_password over MCP. The URL does not change when you do.   Can I also make the page expire or self-destruct? +  Yes. On top of a password you can set an expiry (from minutes to never) or mark the page to burn after a single read. Combined, a passcode plus a short expiry is a practical way to share something sensitive that should not outlive the moment.   Can I password-protect a single HTML page with .htaccess? +  Yes, if the page is served by Apache you control. Put an AuthType Basic block in a .htaccess file, wrap it in a Files directive naming the one page, and point it at an .htpasswd file of users. Nginx does the same with auth_basic in a location block. It needs a server you run: static hosts do not execute .htaccess.   Can JavaScript password-protect a static page? +  A JavaScript prompt that hides content is not protection: the full page still arrives in the browser, so anyone can read it from view-source. Client-side encryption tools such as StatiCrypt are the real version, encrypting the HTML so the password decrypts it locally. The trade-offs are re-encrypting on every edit, no revocation, and no idea who opened it.
Keep reading

## Related guides

   -  [ Are published Claude artifacts public? How to make one private Publishing a Claude artifact creates a public link that may be indexed by search engines. ](/make-claude-artifact-private)
-  [ Share Claude artifacts privately The same flow for a Claude artifact, with the passcode the source lacks. ](/share-claude-artifacts)
-  [ Private HTML hosting The unguessable-URL model the password sits on top of. ](/private-html-hosting)
-  [ Security at Stacktree How passwords are hashed, plus the other gates and what we do and do not claim. ](/security)
-  [ Pricing Passcodes on every plan; Solo at $19 makes pages permanent. What each plan holds. ](/pricing)
-  [ Viewing without an account What the passcode gate looks like from your client's side. ](/client-view-without-account)
-  [ Share AI-generated work with clients The full agency handoff: polish, gate, your own domain. ](/agency-ai-deliverables)

References

## Sources and further reading

   -  [ OWASP: password storage ↗ The hashing practice behind storing a page password, never in plaintext. ](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
-  [ Apache: .htaccess how-to ↗ The server-side route: basic auth scoped to a single file, if you run Apache. ](https://httpd.apache.org/docs/2.4/howto/htaccess.html)
-  [ MDN: HTTP authentication ↗ How basic auth actually works, and why it is only safe over HTTPS. ](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication)
-  [ MDN: URL fragment ↗ Why the end-to-end-encryption key in the URL fragment never reaches the server. ](https://developer.mozilla.org/en-US/docs/Web/API/URL/hash)

##  Share a page only the right people can open.

 Publish free, set a passcode, send the link. No card, about a minute.

 [ Sign up free → ](https://app.stacktr.ee/?join=1&from=cta_password_protect_html_page)         stacktr.ee  [About](/about) [Blog](/blog) [Changelog](/changelog) [Pricing](/pricing) [Security](/security) [FAQ](/faq) [Made with Stacktree](/made-with)  Building with AI agents? See the [developer docs &rarr;](/developers)

---
Full markdown summary of the Stacktree marketing surface: https://stacktr.ee/llms-full.txt