Can I password-protect an HTML file without a server?

Only with client-side methods (a JavaScript prompt or an encrypted file like PageCrypt), and those are obfuscation, not security. The content reaches the browser before the check runs, so it can be read from the source or brute-forced offline. Genuine protection needs something in front of the file (a server-side gate or an identity-based login) that withholds the content until access is granted.

Is JavaScript password protection secure?

No, not for anything confidential. A browser has to download the page to run the script, so the page (and frequently the password) is in the source. Encrypting the body helps, but you're still shipping the ciphertext to every visitor, which makes an offline brute-force attack possible. Use it only for low-stakes content.

What's better than a password for sharing a confidential HTML file?

Identity-based access. Require the viewer to sign in with their company account (SSO) or with a one-time code sent to their email. You get a real audit trail of who opened the page, you can revoke one person without affecting anyone else, and a forwarded link grants nothing on its own.

Can I require a login instead of a password?

Yes. With gated publishing you publish the HTML file behind company auth, and viewers authenticate with their own Google or Microsoft account. display.dev does this in one command (`dsp publish`), with unlimited viewers on a flat plan, so there's no per-seat cost for sharing widely.

How do I revoke access after I've shared a link?

With a password you can't, except by changing it for everyone. With identity-bound access you remove the one person (or their company email is deprovisioned when they leave) and their access ends immediately, while everyone else keeps working. That per-person control is the main reason confidential content shouldn't sit behind a shared password.

How to Password-Protect an HTML File (and Why a Login Beats a Password)

Two different things get called "HTML password protection"

When someone wants to "put a password on an HTML file," they usually mean one of two completely different mechanisms. They look similar to the person sharing the link. They are not similar at all under the hood.

Client-side protection lives inside the HTML. A script asks for a password, compares it to a value baked into the page (or uses it to decrypt the content), and reveals the page if it matches. The file is already on the viewer's machine before the prompt appears.

Server-side protection lives in front of the HTML. The host checks credentials first and refuses to send a single byte of the protected content until the check passes. The file never reaches the browser unless access is granted.

The difference decides whether you have security or theater.

Client-side password protection is obfuscation, not security

A JavaScript password prompt feels protective. It isn't. The browser has already downloaded the page to evaluate the script, so the content (and often the password itself) sits in the page source. Anyone can open developer tools, read the source, and skip the prompt entirely.

Tools like PageCrypt improve on the naive version by encrypting the page body and shipping ciphertext instead of plaintext. That's better. It's still not safe for confidential content: every visitor receives the encrypted payload, which means anyone who wants in can run an offline brute-force attack against it on their own hardware, for as long as they like, with no server to rate-limit them.

Client-side protection is fine for low-stakes, non-adversarial cases (a surprise page, a soft gate on something that isn't really secret). Treat it as a "please don't peek" sign, not a lock.

Server-side passwords actually gate the file

Server-side protection is the real version. The host stores a hash of the password (bcrypt or similar), prompts the viewer, validates server-side, and serves the HTML only after a correct entry. A wrong password gets nothing back, so there's nothing to inspect or brute-force offline.

You can get this from HTTP basic auth on your own server, from a static host that offers a server-side password feature, or from a managed sharing tool. If the page contains anything you'd mind a stranger reading, this is the floor.

But "real" is not the same as "good enough for confidential work." A correct password still has a structural problem that no amount of bcrypt fixes.

Where every password model leaks

A password protects a document. It says nothing about a person. That gap is where the model breaks down the moment the content actually matters:

The password rides the same channel as the link. You paste the URL in Slack or email, then paste the password right under it. Anyone who can see the message has both. There's no real separation between the lock and the key.
Viewers have nowhere to keep it. By the second visit the password is buried in an old thread or forgotten. A shared password is worse return-visit friction than a one-time code, not better.
There's no record of who opened it. A password can't answer "who viewed this on March 12th?" because it isn't tied to an identity. For SOC 2, for an incident review, for any compliance question, that's a dead end.
It's forwardable. A forwarded URL plus password works exactly as well for the wrong person as the right one. You can't revoke one viewer without changing the password for everyone.

This is why password protection is a pre-SSO-ubiquity pattern. It made sense when authenticating a viewer was expensive. In 2026 the viewer's Google or Microsoft session is one click away.

The 2026 answer: identity-bound access

Instead of protecting the document with a shared secret, protect it with the viewer's own identity. Each person authenticates as themselves, and access is a property of who they are, not what string they typed.

For internal content, that's company SSO: only verified @yourco.com accounts can open the page, every view is attributable, and removing one person revokes their access immediately with no password change and no message to anyone else. For a named outside reviewer, a one-time code to their email does the same job for one person without minting a shared credential.

This is exactly what gated publishing is built for. With display.dev you publish an HTML file behind company auth in one command:

dsp publish ./report.html

You get back a permanent URL. A teammate clicks it, signs in once with their company Google or Microsoft account (about five seconds), and sees the full interactive page. There's no password to share, nothing for them to store, a real audit trail of who opened it, and you can revoke any single viewer on their own. There's no per-seat cost for viewers either, so sharing company-wide doesn't trigger a bill.

display.dev deliberately doesn't offer a per-document password, because for confidential work it's the weaker tool. The login is the feature.

When a password is actually fine

Honesty matters here, because a login isn't always the right call:

The content isn't really sensitive. A draft you'd shrug at if it leaked doesn't need identity. A password (even a client-side one) is enough friction.
You want lead capture, not access control. DocSend-style tools gate a deck behind an email field because the publisher wants the viewer's contact. That's a sales motion, not security. If that's your goal, an email gate beats both a password and SSO.
You're handing a one-off to someone with no account anywhere. A throwaway server-side password can be the path of least resistance for a single non-recurring share.

The rule of thumb: if you'd care who opened it, or you'd ever need to take access away from one person, you want identity, not a password.

Side by side

	Client-side JS password	Server-side password	Identity-bound (SSO / email OTP)
Real protection (can't read source)	❌ obfuscation	✅	✅
Resists offline brute force	❌	✅	✅
Knows who viewed it	❌	❌	✅
Revoke one viewer	❌	❌ (change for all)	✅
Return-visit friction	Re-enter	Re-enter	One-click session
Survives forwarding	❌	❌	✅ (link alone grants nothing)
Audit trail for compliance	❌	❌	✅
Setup	Paste a script	Host feature / basic auth	`dsp publish`

How to publish an HTML file behind company auth

If the file is confidential (a competitive analysis, an architecture proposal, a financial report, anything with customer data), skip the password and gate it with identity:

Install the CLI: npm install -g @displaydev/cli
Authenticate: dsp login
Publish: dsp publish ./your-file.html

You get a permanent, company-scoped URL. Viewers click, sign in with their company Google or Microsoft account once, and see the rendered page with all its interactivity intact. No accounts to create, no password to circulate, and a real record of who opened what.

Not a terminal person? The same thing works from Claude Desktop. Say "publish this behind company auth" and the display.dev MCP tool returns the gated URL right in the conversation.

FAQ