Two ways to put a password on a static page without running a backend — client-side encryption you set up yourself, or a hosted gate you don't. What each actually protects, and which fits a page you're handing to one person.
Search "password protect a static HTML page" and you land in a genuinely useful corner of the web: tools and guides for putting a lock on a page when you don't have — and don't want to build — a backend. The advice is mostly sound. What's usually missing is the one distinction that decides which approach you should pick: what is the password actually protecting against? Answer that first, because the two serverless routes defend different lines.
Tools like StatiCrypt take your HTML and encrypt it into a new file. When someone opens that file and types the password, JavaScript in their browser decrypts the contents on the spot. There's no backend anywhere — which is exactly why it's popular: you can drop the encrypted file on any static host, even one that offers no access controls of its own, and it stays scrambled to anyone without the passphrase.
For a lot of cases that's the right tool, and it deserves credit rather than a caveat-first framing. If you're self-hosting a page and you want it off casual eyes without standing up any infrastructure, client-side encryption does that cleanly.
Its limit is structural, and worth understanding rather than fearing: the encrypted payload is delivered to the reader's machine before the password is entered. The password unlocks a file they already have. Against forwarding, accidental discovery, and casual snooping, that's fine — the passphrase is the wall. Against a threat model where you don't want the contents leaving the server at all until access is proven, a file that's already on the reader's disk is a different situation. This is the same client-side-versus-server-side line that decides what "password protected" actually means on any shared link.
The other route trades "no server anywhere" for "no server you run." You upload the page to a private-link host and set a password on it. There is a server — the host's — but you don't build it, run it, or maintain it. And because there's a real server in the path, it can do the thing client-side encryption structurally can't: hold the file back until the password is verified server-side, so the contents aren't transmitted to anyone who hasn't cleared the gate. The reader who doesn't have the password gets a password form, not your page.
That's the precision hiding inside "without a server." Client-side encryption is without any server. A hosted gate is without your server. When most people ask how to password-protect a page without a backend, the second is what they actually want: they don't want to operate infrastructure, but they're happy for the host to, especially if it means the file stays put until access is proven — and no setup on their side.
Drop a self-contained HTML file, toggle a password, get a private link. The file is held server-side until the password checks out — and password protection is free on every plan. (Want to see the flow first? An anonymous drop at /try needs no signup, though the password toggle lives behind the free account.)
One thing worth naming: on a private-link host the password isn't the only thing standing between your page and the world. Every link already gets an unguessable 32-character URL that isn't listed or indexed, so the page is private by default before any password. The password is a second factor, for when the contents warrant one — so even someone who ends up with the link still can't open the page. Hiding the URL stops discovery; the password stops access by someone who got the URL anyway. The two layers are the reason a private link is a cleaner default than dropping the file in a shared Drive folder, where the access model is coarser and the URL is ordinary.
Both are legitimate answers to "without a server." They just mean different things by it, and defend different lines. Name the threat — casual discovery, or contents that shouldn't leave the server unproven — and the method picks itself.
Anthropic's docs are explicit: on Free, Pro and Max, publishing makes an artifact publicly available to anyone with the link. Org-only sharing is a Team and Enterprise feature. Here's what that means if you're an individual sending work to one named client.
A short-lived link reads as a feature for one-off reviews and a bug for permanent references. The shape of the engagement decides which one the file needs.
Instant hosts trade takedown for tamper-proofing — and most people meet that trade at the worst possible moment. What immutable actually means, why support usually can't help, and the three questions worth asking before you press publish.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.