Guide

How to password-protect an HTML page: six methods, real and fake, ranked for 2026

For a page a client, an investor or a team will open, an email gate on Hostus is the method we recommend: the reader types an email before the page loads, you see who opened it, and there is no shared password to forward. The other five range from a real server-side check to a JavaScript prompt anyone can bypass in view-source. Vendor plans were checked on their own pages today.

Updated 2026-09-07 · by Hostus Team

You have an HTML page (a proposal, a report, something Claude or ChatGPT generated) and you do not want the whole internet reading it. "Password protect" is the search, but a password is only one of three things you might want: to stop strangers, to know who read it, or to make the file unreadable if it leaks. If the page has stakes, the method we recommend is an email gate on Hostus: it names the reader, lets you revoke one person instantly and works on the free plan. The five methods below it each solve a narrower problem, and one solves nothing at all.

Fake security vs real security: what does a password actually do?

Three questions sort every method on this page.

  • Where is the check? If the server decides whether to send the HTML, a reader without the password never receives the content. If the check runs in the browser, the reader already has the content and the check is a curtain.
  • Is it a shared secret? A single password is forwarded as easily as the link. Once it is out, the only fix is to change it for everyone.
  • Does it identify the reader? A password tells you that someone knew it, not who, when, or where they stopped.

Real protection means the content does not reach a browser until a server or a decryption key says so. Fake protection means the content is already on the reader's machine and a script is asking politely. Method 6 is fake. Methods 2 to 5 are real. Method 1 is real access control plus identity, which is usually what the person asking for a password wanted. Stated plainly: an email gate identifies readers and controls access; it does not encrypt the file.

1. Email gate instead of a password (Hostus, free plan, identifies the reader)

Drop the HTML file on Hostus, sign in with a magic link, and switch the doc's access to Email-gated. The reader types an email before the page opens. You choose how strict the gate is:

  • Open: any email lets them in, and you learn who read it. Good for a proposal one person may forward internally.
  • Restricted to a list: only the addresses you typed get through.
  • Restricted to a domain: anyone at client.com, nobody else.

What no password gives you: who opened the page and when, time per section anchored to your headings, and where each reader stopped. Revocation is instant and per person: remove one address and that reader is out on their next load. The gate also covers the page's media (images, video, fonts), so a direct asset link does not bypass it. And with no shared secret, there is nothing to leak or forward.

For the strictest case, switch the same doc to Private: invite-only, each reader signs in with a magic link sent to their address, which verifies the email is real. Public, Private and Email-gated are switchable at any time on the same link.

Free plan: 20 docs, 2 MB of HTML total, both modes included. Paid is $9.99 per month or $49.99 per year. Limits: gating is access control and identification, not encryption; an open gate accepts any address a reader types, so use a list, a domain or Private mode when identity has to be certain. HTML only, no PDF.

2. A hosted password on a static host (Tiiny.host, Static.app, Netlify)

Several drag-and-drop hosts put a password prompt in front of a whole site, checked on their servers before the HTML is sent. Real protection, shared secret: anyone with the link and the password gets in, and you cannot tell them apart. Verified on the vendors' own pages today:

  • Tiiny.host: password protection starts on the Solo plan, $13 a month billed yearly. The free plan (1 active site, 3 MB) and the $5 Tiny plan do not include it. Capturing visitor emails is a separate feature that starts on Pro at $31 a month.
  • Static.app: its help page says you "can protect an entire website or an individual page with a password from your website settings". The pricing page does not list the feature by plan (free is 1 site, 50 MB; Starter is $5 a month), so check their pricing page for whether the free plan includes it.
  • Netlify: site-wide password protection is "available on all Pro plans" ($20 a month) and Enterprise. Basic authentication through a _headers file is also Pro and Enterprise. The free plan has neither.

Pick it if you already host a multi-page site there and one shared password is enough. To revoke one reader you change the password for everyone.

3. .htaccess Basic Auth on your own server

If you run Apache (or nginx with auth_basic), HTTP Basic Authentication is the oldest real method. An .htaccess file points to a password file, the browser shows a login box, and the server refuses to send the page until the credentials match. Each reader can have their own username, and deleting one line revokes one person.

Pick it if you already have a server. You maintain it, the login box looks like 1998, and there is no view log beyond access logs. It does not work on drag-and-drop hosts or GitHub Pages, which have no server you control.

4. StatiCrypt or PageCrypt (client-side AES: real encryption, shared password)

These open-source tools encrypt the HTML itself, so the file can sit on any public host and still be unreadable without the password. Verified on their GitHub READMEs today:

  • StatiCrypt (MIT, github.com/robinmoisson/staticrypt) uses "AES-256 and WebCrypto" with "600k PBKDF2-SHA256 iterations"; the output is a static page that prompts for a password and decrypts in the browser, "no server logic needed". The README states "you can only use one password per page". An optional remember-me stores a salted hash in localStorage.
  • PageCrypt (LGPL, github.com/Greenheart/pagecrypt) uses the native Web Crypto API with PBKDF2 and AES, outputs "a single HTML file, so you can host it anywhere", runs from npx pagecrypt, and can put the password after # in the link so the reader is not prompted.

Real security in the cryptographic sense: without the password the page is a blob. Still a shared secret: anyone with the password reads the page, you never learn who did, and revoking one reader means re-encrypting and re-sending a new password to everyone else. Pick it if the content must survive a leaked link and you can hand the password over a separate channel.

5. An encrypted zip or a PDF password (not a web page any more)

Zip the HTML with AES encryption (7-Zip, or the OS built-ins) or print it to PDF and set an open password. The recipient types the password and reads the file locally. Encryption is real if the tool uses AES; older zip encryption is weak, so check the tool.

The trade: it is no longer a web page. No link, no updates after sending, no forms, no view log, and the password often travels in the same email as the attachment. Pick it if the reader insists on a file, or the content must never touch a server you do not own.

6. A JavaScript prompt() check (fake: readable in view-source)

The tutorial that ranks for this query is a few lines like if (prompt("Password?") !== "secret") location.href = "/". It is not protection. The full HTML, including the password string and the content it guards, has already been downloaded. Right-click, View Page Source, and both are on screen. Disabling JavaScript skips the check. Search engines index the page.

Variants that compare a hash, or fetch a "protected" section from another public URL, fail the same way: the check runs on a machine the reader controls. Do not pick it for anything with stakes; it is a prop for a demo, nothing more.

Which method gives you what?

MethodReal or fake protection?Do you know WHO opened it?Can you revoke one reader?Works on a free plan? (verified)Needs a server?
Email gate or Private mode (Hostus)Real access control before the page loads (not encryption)Yes: typed email plus time per section; Private verifies the addressYes, instantly, per personYes: 20 docs, 2 MB, both modesNo, hosted
Hosted password (Tiiny.host, Static.app, Netlify)Real, server-side; shared secretNoNo, change it for everyoneTiiny: no (Solo, $13/mo yearly). Netlify: no (Pro, $20/mo). Static.app: check their pricing pageNo, hosted
.htaccess Basic AuthReal, server-sidePer username, if you create one eachYes, delete their lineNot applicable: your own serverYes
StatiCrypt / PageCryptReal encryption (AES via Web Crypto); shared secretNoNo, re-encrypt and re-sendYes: free, open source, any hostNo
Encrypted zip / PDF passwordReal if AES; not a web pageNoNoYesNo, it is a file
JavaScript prompt()Fake: content and password in view-sourceNoNoYesNo

The "who" column is where the methods separate: only two of the six can name a reader, and only one does it without you administering accounts.

How do I password-protect a Claude artifact or an AI-generated page?

Claude's Publish button makes an artifact public at a link, with no password or gate. Fine for a page nobody important will open. For a reader who matters, download the artifact as HTML (or ask Claude for one self-contained file with inline CSS and JS), drop it on Hostus, and switch the doc to Email-gated or Private. The same applies to pages from ChatGPT, v0, Lovable or Bolt, as long as the export is a single HTML file rather than a React build. With the Hostus connector, Claude can publish the file for you and you set the gate in the app. The step-by-step, including forms inside the artifact, is in how to share a Claude artifact.

Do not paste a JavaScript password check into the artifact and call it protected. Claude will write one if you ask; it is method 6.

Which should you pick?

Default to the email gate on Hostus: the only free method that names the reader and lets you remove one person. Then the exceptions:

  • Unless the file must be unreadable even if the host is compromised: StatiCrypt or PageCrypt, password sent separately.
  • Unless you run your own server and want per-user logins: .htaccess.
  • Unless a multi-page site already lives on Netlify or Tiiny.host and one shared password is enough: their hosted password, on the plan that includes it.
  • Unless the reader wants a file, not a link: encrypted zip or PDF.

Good to know before you switch

Hostus gates identify readers and control access; they do not encrypt the HTML, so a reader who is let in can save the page like any other. Hostus hosts single HTML files with their media only (no React or SPA build output, no PDF), the link is your-slug.v.hostus.io with no custom domain, the free plan covers 20 docs and 2 MB of HTML total with 100 form responses a month, there are no team seats, and the editor is desktop-only. If the content must survive a leak of the file itself, encrypt it with StatiCrypt and treat the gate as a separate layer.

Questions people ask

Is a JavaScript password secure?

No. A JavaScript check runs after the browser has downloaded the whole page, so the content and usually the password itself are visible with View Page Source, and turning JavaScript off skips the check. Use a server-side gate (Hostus Email-gated or Private, a hosted password, .htaccess) or real client-side encryption (StatiCrypt, PageCrypt) instead.

Can I password-protect a page on GitHub Pages?

Not on a regular account. GitHub's docs state that to publish a Pages site privately your organization must use GitHub Enterprise Cloud, and there is no password feature at all. On GitHub Pages your options are client-side encryption with StatiCrypt or PageCrypt, or hosting the page somewhere with a gate, such as Hostus.

What is an email-gated document?

A document behind a screen that asks the reader for an email address before it opens, instead of a password. On Hostus you can accept any address to identify everyone, restrict to a list or a domain, see who opened it and when, and revoke one reader instantly. It identifies readers and controls access; it does not encrypt the file.

Does an email gate encrypt my HTML file?

No. The gate decides whether the server sends the page; a reader who is let in receives normal HTML and can save it. If the file must stay unreadable after download, encrypt it with StatiCrypt or PageCrypt and accept the shared password that comes with that.

Can I password-protect an HTML page on a free plan?

Yes, with Hostus: Email-gated and Private modes are on the free plan (20 docs, 2 MB of HTML). StatiCrypt and PageCrypt are free and work on any host. Among hosted passwords, Tiiny.host starts on its Solo plan and Netlify on Pro, neither free; check Static.app's pricing page for its plans.

What is the difference between Private and Email-gated on Hostus?

Email-gated asks the reader to type an email and opens the page; you can leave it open, restrict to a list or restrict to a domain. Private is invite-only and each reader signs in with a magic link sent to their address, so the email is verified. Both show who opened the page and when, and both can be switched on the same link at any time.

Is StatiCrypt safe to use for confidential pages?

Its README describes AES-256 through WebCrypto with 600,000 PBKDF2-SHA256 iterations, which is real encryption; the weak point is the password, shared by every reader and often sent in the same email as the link. It also cannot tell you who opened the page. Use a strong password sent over a separate channel, and re-encrypt if it leaks.

Know who opened the page, without a password to leak

Drop the HTML, switch it to Email-gated or Private, send the link. Free for 20 docs, no card.