How to Password-Protect an HTML File in 2026 (5 Methods, Ranked by Real Security)

Last updated: June 2026

TL;DR: The most common way to "password-protect" an HTML file — the JavaScript snippet ChatGPT or Claude hands you — is not protection at all. The password and the content both sit in plain text inside the file the browser already downloaded, readable in seconds via right-click → View Source, DevTools, or by simply disabling JavaScript. Here are the five real methods, ranked worst to best by how much control they actually give you: (1) client-side JavaScript password — insecure, content-hiding only; (2) StatiCrypt / PageCrypt static encryption — moderate, real AES-256 but no tracking or revoke; (3) .htaccess/.htpasswd server Basic Auth — strong but blunt and server-required; (4) password-protected AES-256 ZIP — strong crypto but breaks interactivity; (5) a data room / secure link — strong and granular: a real password plus per-viewer watermark, analytics, instant revoke, and audit, and it renders the HTML live with JavaScript executing so an interactive AI artifact still runs. The global average data-breach cost hit $4.44M in 2025, with the US average above $10M, so the gap between "looks locked" and "is controlled" is not academic.

I'm Deqian Jia, co-founder of Peony, a data room company — and a builder, so I want to start with the situation that almost certainly brought you here. You generated an HTML page in ChatGPT or Claude — an interactive report, a dashboard, a calculator, a client one-pager — and before you send it, you asked the same AI "can you add a password to this?" It cheerfully pasted in a few lines of JavaScript with a prompt() box. It looks like a lock. It is not a lock. That snippet is the single most common piece of fake security on the web, and the persona who gets handed it — a non-technical founder, consultant, or analyst sending one confidential file — is exactly the persona most likely to trust it.

This guide fixes that. I'll walk the five real methods from least to most secure, bust the JavaScript myth in detail (with the precise reasons it fails), and be honest about where the free tools are genuinely fine. The throughline: a password that the recipient's browser can read is not a password. The only methods that work move the check somewhere the browser can't see — a server, or an access-gated link. And one of those methods does something none of the others can: it keeps your interactive AI artifact alive while still locking it down.

What's the fastest way to password-protect an HTML file?

The fastest real method is to stop trying to lock the file and instead share an access-gated link to it. Every file-based method below either fails outright (JavaScript) or trades away something you need — interactivity, tracking, or the ability to revoke. So before the deep dive, here's the one-line decision guide.

Quick guide — match the method to the stakes:

• A throwaway page nobody would bother inspecting? → A client-side JavaScript password "works" but protects nothing — Method 1.
• A low-stakes static page you just want unreadable in View Source? → StatiCrypt or PageCrypt real AES-256 encryption, free — Method 2.
• A page on a server you control, one shared login is fine? → .htaccess + .htpasswd Basic Auth — Method 3.
• A finalized file you'll hand over once and don't need interactive? → Password-protected AES-256 ZIP — Method 4.
• A confidential report or AI artifact going to a client/investor where you need to know who opened it, keep it interactive, and revoke later? → A data room link — Method 5.

The order below is deliberate: worst to best by control. Each method is genuinely fine for some use — I'll concede exactly where — but only the last one combines a real password with per-viewer attribution, live rendering, analytics, and revoke.

Method 1: The client-side JavaScript password (what ChatGPT hands you)

This is the method to avoid, and it's the one you were probably about to use. A client-side JavaScript password is content-hiding, not security — so I'm listing it first specifically to bust it, because it's what AI assistants hand non-technical users by default.

How it works: JavaScript inside the HTML file compares whatever the visitor types against a password that's baked into the page — sometimes in plain text, sometimes base64-encoded, "obfuscated," or hashed to look more serious. On a match, the script un-hides a hidden <div>, writes the content into the page with innerHTML, or redirects to the "real" page. The catch is fatal: both the password and the protected content live inside the file the browser already downloaded.

Here's why it fails, concretely — and these aren't edge cases, they're the first three things anyone curious would try:

• View Source / DevTools. Right-click → "View Page Source," or open DevTools, and the password and the hidden content are right there in the markup. Hashing the password doesn't help if the content itself is in the file — you can read the content without ever knowing the password.
• Disable JavaScript. Turn JS off in the browser and the password check never runs — but the hidden content often still loads into the DOM. The "lock" simply doesn't execute.
• "Save Page As" / Network tab. Saving the page or watching the Network tab captures the full payload, password gate bypassed entirely.

Obfuscation buys you seconds against a casual reader and nothing against a determined one. To a technical client or an investor's analyst, finding a password sitting in your page source is worse than no lock at all — it signals you don't understand web security. (More on that professionalism risk in the FAQ below.)

Pros: Free, instant, no server, no tools. Genuinely fine for hiding a surprise party page or a non-confidential easter egg from casual eyes.

Cons: Not security in any real sense. Password and content are both readable. Trivially bypassed. No tracking, no revoke, no per-viewer identity. A red flag to any technical recipient.

Best for: Truly non-confidential pages where "mildly inconvenient to read" is the entire goal. Never for anything you'd be embarrassed to leak.

Method 2: StatiCrypt / PageCrypt (static-site encryption)

This is the first method that's actually real — a genuine step up from Method 1. StatiCrypt and PageCrypt are open-source tools that AES-256-encrypt your HTML so View Source shows only ciphertext, not your content. If you need a free, no-server way to make a low-stakes page genuinely unreadable to a casual snoop, this is the honest choice.

How it works: You paste your HTML (or upload the file) into the tool and set a password. It AES-256-encrypts the page body and outputs a single static .html that is real ciphertext plus a small decryptor script. When a visitor opens it and types the password, their browser derives the key and decrypts the content client-side via the WebCrypto API. StatiCrypt uses AES-256-CBC with PBKDF2-SHA256 at 600,000 iterations and a random salt — that's a serious, modern key-derivation setup, not a toy. PageCrypt does the same job (AES-256, client-side decryption); both are free and open source.

The critical honest caveat: the full ciphertext travels with the file. Because the entire encrypted payload sits on the recipient's machine, an attacker can run an offline brute-force or dictionary attack at their leisure — there's no server to rate-limit them. StatiCrypt itself warns you to use a long, unusual password (16+ characters) and notes that genuinely at-risk users "should probably use something else." And like every file-based method, it has no access tracking, no per-viewer identity, and no revoke — one shared password works forever for anyone the file is forwarded to.

Pros: Free and open source. Real AES-256 encryption — View Source shows only encrypted blobs. No server needed. A non-technical person can do it from a web form in two minutes. Honest, well-documented tooling.

Cons: Whole encrypted payload ships to the recipient, so offline brute-force is possible — security rests entirely on password length. No tracking, no per-viewer watermark, no revoke. One shared password, forwardable forever. No way to keep different viewers separate.

Best for: A private-but-not-highly-sensitive static page you want unreadable in View Source — a draft, a personal page, a low-stakes handout where you don't need to know who opened it.

Method 3: .htaccess + .htpasswd (server-side Basic Auth)

This is strong protection — but blunt, and it requires a server you control. With .htaccess and .htpasswd (Apache), or auth_basic + auth_basic_user_file (nginx), the server enforces the password, not the page. That's the structural fix that Methods 1 and 2 can't offer: the content is never sent to the browser until valid credentials arrive.

How it works: You create a .htpasswd file where the htpasswd utility stores usernames with hashed passwords (bcrypt or MD5). A small .htaccess directive points Apache at that file and requires authentication for the directory. When someone requests your HTML, the server responds with a native browser login dialog and refuses to send the page until the browser supplies valid credentials. One useful detail: Apache and nginx use the same htpasswd-format file, but nginx does not read .htaccess — you configure auth_basic directly in the nginx server block instead.

The honest caveats are about prerequisites and bluntness, not about the crypto:

• HTTPS only. HTTP Basic Auth sends credentials base64-encoded, which is encoding, not encryption — over plain HTTP they're trivially sniffable. You must serve over HTTPS.
• You need a server you control. This doesn't work on pure static hosting like raw GitHub Pages; you need Apache or nginx you can configure.
• All-or-nothing. There's no per-viewer watermark, no screenshot protection, no analytics, and no audit trail. Revoking one person means editing the password file and rotating the shared credentials for everyone.

Pros: Genuinely strong — the server enforces it and never hands over the content unauthenticated. No JavaScript trickery. Standard, battle-tested, free if you already have hosting.

Cons: Requires a server you control and command-line setup (not for the non-technical primary persona). HTTPS-mandatory. Blunt: no per-viewer identity, no analytics, no watermark, no granular or per-person revoke.

Best for: A developer or technical small-business owner protecting a page on their own Apache/nginx server, where one shared login for a known group is acceptable and you don't need to know who viewed what.

Method 4: A password-protected AES-256 ZIP

The crypto here can be strong, but the workflow quietly fails the use case — which is why I rate it weak-to-moderate for this job despite AES-256 being solid. You compress the .html and its assets into an encrypted archive and send the password separately.

How it works: Using 7-Zip, WinRAR, or your operating system's built-in compression, you create an AES-256 archive (this is important — avoid legacy ZipCrypto, which is cryptographically broken and crackable in minutes). The recipient downloads the archive, opens it with a compatible tool, types the password, and extracts the files before they can open the HTML. Then you send the password on a separate channel (text, a call, a different app), never in the same email as the file.

The caveats are where this method loses for an HTML deliverable:

• It breaks interactivity. The HTML can't render or run until it's unzipped to disk. Your live, interactive ChatGPT or Claude artifact is dead weight inside the archive — the charts and buttons only work after the recipient extracts everything, and even then it's running from a loose local file.
• Metadata leaks. AES ZIP encrypts the file contents but not the archive metadata — filenames, sizes, and timestamps are still visible. A folder named Acquisition_Model_Confidential gives the game away before anyone types the password.
• Tooling friction. Windows' built-in extractor historically can't open AES-encrypted archives — the recipient needs 7-Zip or WinRAR installed, which is a real ask for a non-technical client.
• Uncontrolled once extracted. The moment the recipient unzips, the files are loose, uncontrolled copies. No tracking, no revoke, no per-viewer identity — the protection evaporates on extraction.

For the file-at-rest, this is genuinely strong (credit AES-256). For sending a confidential interactive report to a client you want to track, it's the wrong shape. See our deeper guide on how to password-protect a ZIP for the step-by-step.

Pros: Strong AES-256 encryption at rest. Free with software you likely already have. Works offline.

Cons: Breaks interactivity — the HTML can't run until extracted. Leaks filenames/sizes in metadata. Needs 7-Zip/WinRAR on the recipient's side. Once extracted, files are uncontrolled — no tracking, no watermark, no revoke. Looks clunky for a client deliverable.

Best for: Handing over a finalized, non-interactive file once, to someone you trust to manage it, where you don't need engagement data or the ability to pull it back.

Method 5: A data room / secure link (the method that keeps the artifact alive)

This is the best method by control — and the only one that keeps your interactive HTML running while it locks it down. Instead of trying to lock a file you hand over, you upload the .html/.htm and share a link. The viewer authenticates (password and/or email verification) and views it in the browser — and a data room built for this renders the HTML natively, with JavaScript executing, so a Claude- or GPT-generated dashboard, calculator, or live model actually runs for the recipient instead of being flattened to a dead PDF. No code required.

How it works: You upload the file to a platform like Peony and send a tracked link. The viewer opens the link, verifies their identity, and the artifact renders live in the in-browser viewer. Around that live render, the platform wraps a control layer no self-contained file can offer:

• A real password / email gate the recipient's browser can't read around — the content is never handed over until the viewer is authenticated, the same structural win as Basic Auth.
• Per-viewer dynamic watermark stamped with each viewer's name, email, and timestamp burned onto the live render (Data Room plan and up).
• Screenshot protection on desktop (Business and up) plus Screenshield mobile screen-capture blocking (Data Room and up).
• Page-level analytics — who opened it, when, and which sections they spent time on.
• Instant revoke — cut any individual viewer's access in one click, without disturbing anyone else, even after you've sent the link.
• A full audit trail of every open.

This is the piece the persona-map calls control after sending — and it's the entire reason a link beats a file. Every method 1–4 shares one blind spot: once it's out, you have no idea who opened it and no way to pull it back. A data room link is the only method that closes that gap. (I wrote a focused companion piece on exactly this for AI output — how to securely share Claude artifacts — and a market survey of which data rooms support HTML display, most of which secretly convert your HTML to a PDF and kill the interactivity.)

The honest trade-off: you give up "just send the file." You need a hosting platform rather than a raw attachment, and the strongest controls are tier-gated (more on pricing below). But in return you get revocability, per-viewer attribution, live interactivity, and an audit trail that no self-contained file can provide. For a confidential report, that trade is the whole point — and it's why 5,900+ customers run their sensitive sharing on Peony.

Pros: Real password the browser can't bypass. Renders HTML live with JavaScript executing — interactive AI artifacts keep working. Per-viewer watermark, screenshot protection, page-level analytics, instant revoke, and audit trail. No coding. Looks professional.

Cons: Requires a hosting platform, not a raw file. Strongest controls (dynamic watermark, mobile Screenshield) are on the Data Room tier ($52/admin/month); connecting an external LLM with full audit is Enterprise. You're trading "just attach it" for control.

Best for: Confidential reports, client deliverables, investor one-pagers, and interactive AI artifacts where you need a real gate, must keep the page interactive, and want to know who opened it and be able to revoke.

Quick comparison: which HTML password method should you use?

The honest one-screen view. Notice the security spectrum runs insecure → moderate → strong-but-blunt → strong-crypto-wrong-workflow → strong-and-granular — and only the last row gives you tracking, live rendering, and revoke at once.

Is a JavaScript password on an HTML file ever real security?

No — and this is the single myth worth nailing down, because it's the one the AI assistants perpetuate. The reason is structural, not a matter of writing the snippet better: for the browser to check a password client-side, it must already have the password and the content in hand. Both arrive in the download. Hashing the password, base64-encoding it, minifying the script, "obfuscating" the check — none of it changes the fact that the protected content is sitting in the file the visitor's machine has fully received.

Contrast that with the two methods that actually work. With .htaccess/Basic Auth, the server holds the content and won't release it until credentials check out — the browser never sees the protected bytes unauthenticated. With a data room link, the platform holds the content and renders it only to an authenticated viewer — same structural property. The dividing line across all five methods is exactly this: where does the check happen, and is the content released before it passes? Client-side JavaScript fails because the content is released first and checked second. Everything genuinely secure releases the content second, after the check passes.

This is also why ChatGPT and Claude are not "wrong" to generate the snippet — you asked for a password prompt and they gave you one. They just can't change the fundamental constraint of running in the user's browser. With an Ahrefs study finding 74.2% of newly created web pages in April 2025 contained AI-generated content, a lot of HTML is now AI-built — and a lot of fake password snippets are riding along with it. Knowing the difference between content-hiding and a real gate is now a basic literacy skill.

Practical tips for actually protecting an HTML file

A few field-tested habits that matter across whichever method you land on:

• Send the password on a separate channel. If you use StatiCrypt or an encrypted ZIP, never put the password in the same email as the file. Use text, a call, or a different messaging app. NIST's digital identity guidelines favor long, unique passphrases over short complex ones — a 16+ character phrase beats P@ss1.
• Match the method to the stakes, not your comfort. A public FAQ doesn't need encryption; investor financials shouldn't sit behind a JavaScript prompt. The most common security failure here is mismatch in both directions.
• Assume anything client-side can be captured. Even a real watermark is attribution and deterrence, not capture-prevention — someone can photograph the screen with a phone. The point of a per-viewer watermark is that the leaked copy carries the leaker's identity, which changes behavior; it doesn't make the screen un-photographable. Don't oversell any tool, including ours.
• If it's an interactive AI artifact, protect it without flattening it. A password-protected PDF or ZIP kills the interactivity that made the artifact worth sending. If the charts and buttons matter, you need a method that keeps the HTML live — which in practice means a data room link that renders it. Peony's supported file formats lists HTML as natively rendered with JavaScript executing.
• Plan for revoke before you send, not after the leak. Ask yourself: if I needed to cut this person off in an hour, could I? With a file, the answer is no. With a link, it's one click.

Does Peony's data room render the HTML live or flatten it to a PDF?

It renders it live, with JavaScript executing — and that's the category-defining difference. Most "HTML-supporting" tools quietly convert your .html to a PDF on upload, which secures the file but kills the JavaScript, freezing your interactive model into a dead screenshot. Peony renders .html and .htm natively in the in-browser viewer with JavaScript actually running, so a Claude- or GPT-built dashboard, calculator, or live model works for the recipient exactly as it did in your browser — sliders move, toggles toggle, tables recompute.

That live render is what makes the control layer meaningful: the per-viewer dynamic watermark, screenshot protection, page-level analytics, and instant revoke are wrapped around a running artifact, not a flattened image. HTML renders on every Peony tier — including the free plan — so you can show a live interactive file for $0. The control layer is where pricing comes in: desktop screenshot protection, Simple NDA, download prevention, AI document Q&A, and page-level analytics are on the Business plan ($30/admin/month); the per-viewer dynamic watermark on the live render, Screenshield mobile blocking, advanced NDA, granular permissions, and unlimited rooms are on the Data Room plan ($52/admin/month, Most Popular). This is exactly the gap I detail in which data rooms support HTML display: the field splits into convert-to-PDF, display-without-control, and render-live-with-control — and only the last keeps your AI artifact both alive and governed. Peony is SOC 2 Type II certified, and it's why 5,900+ customers send their sensitive work through it.

Bottom line

The method ChatGPT hands you — a JavaScript password in the file — is the one to delete. It's content-hiding, not security: the password and content are both readable in View Source, and to a technical client it reads as a red flag. From there, match the method to the stakes:

• Truly non-confidential page → a JS snippet "works," but understand it protects nothing.
• Low-stakes static page, just keep it out of View Source → StatiCrypt or PageCrypt (free, real AES-256, no tracking).
• Page on a server you control, shared login fine → .htaccess/.htpasswd Basic Auth (strong, HTTPS-only, blunt).
• Finalized, non-interactive file handed over once → AES-256 ZIP (strong at rest, breaks interactivity).
• Confidential or interactive report where you need to track and revoke → a data room link — the only method that combines a real password, a per-viewer watermark, analytics, instant revoke, and a live HTML render that keeps your AI artifact running.

The deciding question is never "does it look locked?" It's "where does the password check happen, can I keep the page interactive, do I know who opened it, and can I pull access back?" Only one of these five methods answers yes to all four. With the US average breach cost above $10M in 2025 and phishing now the most common breach vector at 16% of breaches, averaging $4.8M, the gap between a lock that looks real and one that is real is worth getting right.

Frequently asked questions

I made an interactive report in ChatGPT — should I password-protect my HTML file with JavaScript or use a real tool to share it securely?

Don't rely on the JavaScript password. The snippet ChatGPT hands you bakes both the password and the content into the file the browser already downloaded, so anyone can right-click View Source, open DevTools, or just disable JavaScript and read everything in seconds — it's content-hiding, not security. If the report is genuinely confidential and going to a client, share it through a real tool instead: a data room link that authenticates the viewer, renders your HTML live (so an interactive ChatGPT or Claude artifact still runs), stamps a per-viewer watermark on the page, tracks who opened it, and lets you revoke access after you send it. The JavaScript password is fine only for a low-stakes page nobody would bother inspecting; for anything you'd be embarrassed to leak, it's the wrong tool.

I'm not technical — should I use StatiCrypt or a data room to put a password on my HTML report before sending it to a client?

Use StatiCrypt if the report is low-stakes and you just want it unreadable in View Source — it genuinely AES-256-encrypts the page, it's free, and a non-technical person can do it from a web form in a couple of minutes. Use a data room if the report is confidential, you're sending it to a specific client, and you care who opens it. StatiCrypt ships the entire encrypted file to the recipient, so it can be brute-forced offline, it has no view-tracking, no per-viewer identity, and one shared password works forever for anyone it's forwarded to. A data room flips all of that: the file never leaves the platform as a raw download, each viewer authenticates, you get a per-viewer watermark and page-level analytics, and you can revoke access in one click. The honest rule of thumb: StatiCrypt for a private-but-not-sensitive page, a data room for a client deliverable where a leak has real consequences.

I want to send this to one client — how do I add a password to an HTML file without writing any server code?

You have three no-server-code options, in rising order of real protection. First, StatiCrypt or PageCrypt: paste your HTML into the tool, set a password, and download a single self-contained encrypted .html you can email — no server, genuine AES-256, but no tracking or revoke. Second, an encrypted ZIP: compress the .html and its assets into an AES-256 archive with 7-Zip, WinRAR, or your OS, and send the password on a separate channel — though the recipient has to unzip before the page will run, which breaks interactivity until they extract it. Third, and best for a client deliverable, a data room link: upload the .html to a platform like Peony and share a link instead of the file — no code at all, the viewer authenticates in the browser, your HTML renders live, and you keep tracking, a per-viewer watermark, and instant revoke. All three avoid touching a server; only the data room lets you see who opened it and pull access later.

I generated this page with ChatGPT — how do I password-protect the HTML before emailing it to a client?

Skip the password snippet ChatGPT offers to add — it puts the password in plain text inside the file, so it protects nothing. For a real gate without coding, you have two good paths depending on stakes. If the page is low-stakes, run it through StatiCrypt to AES-encrypt the file, then email the encrypted .html and share the password separately. If it's a confidential client deliverable, don't email the file at all — upload it to a data room and send a link. The advantage of the link for a ChatGPT-generated page specifically is that a good data room renders the .html live with JavaScript executing, so your interactive artifact still works for the client, while you layer on viewer authentication, a per-viewer watermark, open-tracking, and the ability to revoke access the moment the engagement ends. Emailing a raw or JavaScript-'protected' file gives you none of that and can't be undone once it's sent.

Before I send this to an investor — is putting a password in HTML JavaScript actually secure, or can anyone just view the source code?

It is not secure, and yes, anyone can view the source code. A client-side JavaScript password compares the value someone types against a password that is sitting inside the same file the browser already downloaded — so the password, and all the 'protected' content, are right there in the source. A right-click and View Source, or opening DevTools, reveals both in seconds. Worse, disabling JavaScript entirely skips the check while the hidden content still loads, and 'Save Page As' or the Network tab captures everything regardless. Obfuscating or base64-encoding the password slows a curious reader by a few seconds, not a determined one. It is content-hiding dressed up as security. For an investor — exactly the kind of sophisticated reader who might open DevTools or who works with people who would — a JavaScript password is a real red flag, not protection. Use server-side auth or an access-gated data room link instead.

Someone told me the password snippet ChatGPT gave me is fake — is client-side HTML password protection a red flag?

They're right, and yes, it can read as a red flag to a technical recipient. Client-side HTML password protection — whether it's a prompt() box, a hardcoded check, or an 'obfuscated' password — only ever pretends to protect the page, because the browser has to download the whole file (password and content included) before the check runs. Anyone who opens View Source or DevTools sees that the lock is theater, and to an investor, engineer, or security-conscious client that signals you don't understand how web security works. The fix isn't a cleverer snippet; it's moving the password somewhere the recipient's browser can't see it. That means either the server enforcing it (HTTP Basic Auth) or an access-gated platform enforcing it (a data room link), where the content is never handed over until the viewer is authenticated. Both of those are real; the in-file JavaScript password never is.

For sending a report to a client — what's the difference between a JavaScript password and .htaccess / .htpasswd protection?

The difference is who checks the password and whether the content is handed over before that check. A JavaScript password lives inside the HTML file: the browser downloads the entire page — content and password — and only then runs a check that anyone can read in View Source or skip by disabling JavaScript. It protects nothing. .htaccess and .htpasswd protection is enforced by the server (Apache, or auth_basic on nginx): the server refuses to send the HTML at all until the browser supplies valid credentials, which are verified against a hashed password file the visitor never sees. That's genuinely strong — but it's blunt and has prerequisites: you need a server you control (it won't work on pure static hosting), it must run over HTTPS or the credentials are sniffable, and it's all-or-nothing, with no per-viewer watermark, no analytics, and no easy way to revoke one person without rotating the shared password. So .htaccess is real protection where JavaScript isn't; a data room link adds the per-viewer control and tracking that Basic Auth lacks.

I'm emailing an HTML deck to a partner — can someone download the file and remove the password, or forward it to someone else?

If the password lives in the file, yes, on both counts. A JavaScript-'protected' HTML file can have its password removed in seconds by anyone with the file — View Source, delete the check, save — and it can be forwarded to anyone, who then has the same removable lock. A StatiCrypt-encrypted file is much better at rest (the content really is ciphertext), but it can still be forwarded freely, and since the whole encrypted payload travels with the file, a recipient or anyone they forward it to can attempt an offline brute-force at their leisure. An encrypted ZIP has the same forward-and-it's-gone problem: once someone extracts it, the files are loose, uncontrolled copies. The only way to stop 'download, strip, forward' is to never hand over the file — share an access-gated link instead, so the content stays on the platform, each viewer is authenticated and identified, and you can revoke the link the moment it's been forwarded to someone it shouldn't reach.

After I send my HTML report, can I see who opened it and revoke access to the link?

Not with any file-based method — and that's the whole reason to use a link instead. A JavaScript password, a StatiCrypt file, an .htaccess-protected page with one shared login, or an encrypted ZIP all share the same blind spot: once it's out, you have zero visibility into who opened it, and no way to pull it back. .htaccess can at least block future access if you rotate the shared password, but that locks out everyone, and it still can't tell you who viewed what. A data room link is built for exactly this: you get page-level analytics showing who opened the report, when, and which sections they spent time on, and you can revoke any individual viewer's access in one click without disturbing anyone else. In Peony, page-level analytics come on the Business plan ($30/admin/month) and instant revoke is available across Peony's plans; the per-viewer dynamic watermark that stamps each leaked screenshot with the viewer's identity is on the Data Room plan ($52/admin/month).

I built this in Claude — will a JavaScript-password HTML page look unprofessional or sketchy to a client or investor?

To a non-technical client it probably looks fine; to a technical client or any investor, it can read as amateurish. The risk is that the kind of person you most want to impress — an engineer doing diligence, a security-conscious operator, an investor's analyst — is exactly the kind of person who might open DevTools, notice the password is sitting in the source, and quietly conclude you don't take security seriously. Even if they don't inspect it, a clunky pop-up prompt asking for a password before a slick Claude-built artifact loads undercuts the polish of the thing you built. A clean, branded access link that asks them to verify their email and then renders your interactive report live looks far more professional, and it's the difference between 'I hacked a password box onto a file' and 'I sent you a proper, controlled deliverable.' If presentation matters — and to an investor it always does — share a link, not a JavaScript-locked file.

It's just one report — what's the cheapest way to password-protect an HTML file, and are the free tools actually secure?

The cheapest methods are free: a raw JavaScript password (free but not secure — skip it), StatiCrypt or PageCrypt (free and genuinely AES-256-encrypted, so safe for a low-stakes page), and an encrypted ZIP using software you already have (free, strong crypto, but it breaks interactivity and looks clunky for a deliverable). So yes, free tools can be real — StatiCrypt actually encrypts — but 'secure at rest' is not the same as 'controlled': none of the free options let you see who opened the report, identify each viewer, or revoke access after sending, and all of them can be forwarded freely. For one genuinely confidential report where you need to know who opened it and be able to cut access, a data room is worth it — Peony renders the HTML live for free on its free tier, and the control layer (per-viewer watermark, advanced controls) starts at $52/admin/month on the Data Room plan. The honest answer: free is fine for a private-but-not-sensitive page; pay only when a leak would actually cost you something.

Related Resources

• How to securely share Claude artifacts — the focused companion guide for locking down AI-generated interactive output.
• Which data rooms support HTML display — which tools render HTML live versus secretly converting it to a PDF.
• How to password-protect a ZIP — step-by-step AES-256 archive encryption done right.
• How to password-protect a Notion page — the same security spectrum applied to Notion content.
• How to send a password-protected PDF — when a flattened, non-interactive snapshot is the right call.
• Password protection, watermarks, screenshot protection, page analytics, and revoke access — the control-layer features that wrap a shared HTML file.
• Pricing — Free, Business, Data Room, and Deal Team tiers explained.
• Solutions for fundraising, consulting, and due diligence — the workflows this guide is written for.