The tutorial worked for the person who wrote it. It does nothing on a static host, because .htaccess is an Apache file and a static host doesn't hand you an Apache to configure. What the file is actually doing up there, what to delete today, and what to use instead.
You followed a guide. Create .htaccess, add AuthType Basic, generate .htpasswd, upload both, done — the guide even had a screenshot of the browser's password prompt. You pushed it, opened your page, and the page just… opened. No prompt. No error either.
The tutorial wasn't wrong. It was written for a server you don't have.
.htaccess is a feature of one specific web serverApache's documentation is unambiguous about what these files are: .htaccess files, it says, are "distributed configuration files" that "provide a way to make configuration changes on a per-directory basis." That's the whole story. It's not a web standard, and it's not a convention browsers understand. It's a way of handing chunks of Apache's configuration to people who can't edit Apache's main configuration file.
Which means the file only does something if an Apache is reading it. Nothing else in the stack cares. Your browser doesn't; the CDN doesn't; the storage bucket holding your HTML doesn't. Nginx, the other server you'll meet most often, is built around a single central config and has no equivalent per-directory override at all.
Here's the part the tutorials skip, because when they were written "hosting a page" usually meant renting space on a shared Apache box.
GitHub describes Pages as a service that "takes HTML, CSS, and JavaScript files straight from a repository on GitHub, optionally runs the files through a build process, and publishes a website." Read that as an architecture rather than marketing: your files go from a repository to a published site. There is no server of yours in that sentence, and therefore no server config for a per-directory file to override.
The tell, on any static host, is that it has invented its own mechanism for the things .htaccess used to do. Netlify's docs, for instance, tell you to configure redirects in a plain-text _redirects file or in a netlify.toml — a config format that wouldn't need to exist if .htaccess were being read. When a platform ships its own config file, that's your answer about the other one.
So your .htaccess did upload. It is sitting in your deploy right now. It is a text file that nothing has ever opened.
And this is precisely why it costs people an afternoon: an ignored config file and a working config file look identical from outside. There's no error to search for. The page loads, which is what a correctly-configured page also does. You end up re-checking your syntax, regenerating the hash, trying a different AuthType — debugging a file that was never in the conversation.
None is the defaultWorth knowing before you go rent an Apache to fix this, because the same silence happens there.
Apache's docs: "The default value of AllowOverride is None. This means .htaccess files are completely ignored unless you explicitly enable them for a directory." Shared hosting providers typically switch it on, which is why the tutorials work in their context. A VPS you configured yourself, or a managed platform that owns the Apache config, may well have it off — and if the platform owns that config, it isn't yours to change.
Apache goes further and recommends against .htaccess when you have the main config available: put "user authentication, mod_rewrite rules, and anything else you might be tempted to put in .htaccess" in the main configuration instead, since those directives load once at server start rather than on every request.
The inert .htaccess is embarrassing, not dangerous. .htpasswd is the one to deal with today.
It contains a username and a password hash. Static hosts generally serve what's in the directory, and whether a particular host or build tool filters dotfiles varies — Jekyll-based builds skip some, other pipelines copy everything. That variation is the problem: you'd have to verify your specific host's behaviour to know, and the safe assumption is that anything you uploaded is reachable by anyone who guesses the filename, which is not a hard guess.
So: delete both files from the repository or upload, and change that password anywhere else you've used it. A bcrypt or MD5-crypt hash isn't plaintext, but it's a head start for an offline guess, and it was never supposed to be a public object.
Strip away the mechanism and a password is one thing: something in the path that can refuse the request before your page goes out. Three honest shapes, and they defend different lines.
Your host's own access control. Some platforms offer site-level passwords or protected deploy previews, usually on paid plans. If you're already on one of these, this is the native answer and you should use it — it's one setting rather than a new tool.
Client-side encryption. Tools like StatiCrypt encrypt the page into a file that decrypts in the reader's browser. Genuinely serverless, works on any static host including the one that just ignored your .htaccess. Its structural limit: the encrypted contents reach the reader's machine before they type the password. Fine against forwarding and accidental discovery; a different situation when you don't want the contents leaving at all until access is proven. We've written up what "password protected" really means on a shared link, and the two serverless routes side by side.
A private-link host. You upload the page, toggle a password, and the host holds the file back until the password verifies server-side. There's a server — theirs — so it can do the thing client-side encryption can't. You administer nothing.
Drop the HTML file, flip the password on, send the link. The file stays server-side until the password checks out, and the password toggle is free on every plan — no Apache, no AllowOverride, no hash file to leave lying around.
If the page is a client deliverable, a draft, or anything with one intended reader, the private-link route is the shortest path and the URL is unguessable before you even add the password. If the page belongs on a site you're already running and your platform has an access-control setting, use that. If you're committed to self-hosting on a static host and the threat model is casual discovery, client-side encryption is the right tool and it's genuinely good at that job.
If what you actually need is per-user logins, sessions, or roles, none of the above is it — that's an application with a backend, and Vercel or Netlify with serverless functions is where that belongs. Knowing which of these you're in is most of the decision.
What none of them are is .htaccess on a host that never had an Apache. That file isn't misconfigured. It's just somewhere nothing reads.
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.
You open your host's protection settings and get an upgrade screen instead. The question isn't how to add a password — it's whose free plan has that switch, what the switch actually locks, and when paying for it beats moving.
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.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.