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

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.

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.

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 can be made public, but there is no passcode option, so "shared" means "anyone with the link." Claude Code artifacts and Codex Sites 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.
• 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.