To protect a URL with a password, you need to decide where the check happens: at the redirect itself, at the web server, or inside the application the link leads to. Only two of those three are real security — a password prompt built with client-side JavaScript can be bypassed by reading the page's source code. The right method depends on whether you're hiding a link from casual viewers or genuinely restricting access to sensitive content.
TL;DR:
- A password on a URL can live in three places: the redirect/shortener layer, the web server, or the destination app — only the last two enforce anything real.
- Client-side JavaScript password prompts are not security; the password and the protected content both sit in the page source, visible to anyone who opens dev tools.
- HTTP Basic Authentication is simple and standards-based, but it sends credentials with every request and must run over HTTPS or it leaks the password in plain text.
- Password-protected pages won't get indexed by Google, which is usually fine — it's often the point.
- If you just need to gate a short link without standing up a server, a shortener with built-in password protection is the fastest honest option.
Table of Contents
- The Three Places a Password Can Actually Live
- Why a JavaScript Prompt Isn't the Same as a Password
- How to Protect a URL with a Password: Matching the Method to the Risk
- Server-Level Protection: HTTP Basic Auth and Its Trade-offs
- What a Password Prompt Doesn't Stop
- Get a Password-Protected Link Without Renting It Monthly
- Frequently Asked Questions
- Sources
The Three Places a Password Can Actually Live
A password check on a link has to run somewhere, and where it runs determines whether it's doing anything at all. There are three realistic options: the redirect layer (a URL shortener or link page that asks for a password before forwarding the visitor), the web server layer (the server itself refuses to serve any content until credentials are supplied), and the application layer (the destination page has its own login system, like a client portal or a member site).
Each layer protects a different thing. A redirect-layer password protects the link — it stops someone from guessing or clicking through to the destination without a code, but once they're in, the destination itself is usually open to anyone with the direct URL. A server-layer password protects the resource — nothing on that path loads without authentication, full stop. An application-layer password protects the account — it's the most flexible but also the most work to build and maintain.
If you're sharing a single file, a draft, or a client-facing dashboard link, you generally want the password to sit as close to the content as possible. The closer it sits to the content, the harder it is to accidentally expose that content through a second, unprotected link to the same file.
Why a JavaScript Prompt Isn't the Same as a Password
A lot of "password protect this page" tutorials amount to a bit of JavaScript that hides content until a visitor types a string that matches a value baked into the page. This looks like protection. It is not. The password and the content it's "protecting" both download to the visitor's browser the moment the page loads — the script is just choosing not to display them yet. Anyone who opens the browser's developer tools, views the page source, or disables JavaScript can see everything the prompt was supposed to block.
This matters because it's the most common way people try to protect a URL with a password without touching a server. It's fine for keeping a page off casual search traffic or stopping someone from stumbling onto a draft. It does nothing against anyone who knows how to right-click "View Page Source," which is not a high bar.
A password checked entirely in the browser isn't a lock. It's a note taped over the lock, in the same room as the key.
How to Protect a URL with a Password: Matching the Method to the Risk
The method you pick should match what you're actually afraid of. Ask one question first: if the password leaked, what's the realistic damage? A link to a draft blog post and a link to a signed contract do not carry the same risk, and they shouldn't get the same treatment.
Three common approaches, compared
| Method | Where the check happens | Real security? | Best for |
|---|---|---|---|
| JavaScript prompt | Browser (client-side) | No — password and content ship together | Keeping casual visitors off a staging page |
| Shortener/redirect password | Server, before the redirect fires | Yes, for the link itself | Gated downloads, pre-launch pages, client links shared by text/email |
| HTTP Basic Auth / server auth | Web server, before any content loads | Yes, for the whole resource | Internal tools, staging environments, admin paths |
| Application login | App backend, with sessions | Yes, and most flexible | Portals, dashboards, anything needing per-user access |
For a one-off link you're sending to a handful of people — a proposal, a private video, a pre-release page — a shortener with a built-in password feature is the least amount of work for a real result, because the check happens server-side before the redirect ever fires. How to Password Protect a URL (What Actually Works) walks through the exact setup for that case if you want the step-by-step.
Pro Tip: If you want click analytics on a password-protected link, put the password check at the redirect layer rather than on the destination page. A redirect-layer check still logs the click (and often whether the password attempt succeeded or failed) even if the visitor never gets past the prompt — the destination page, by contrast, only sees traffic from people who already got through, which undercounts how many people actually tried the link.
Server-Level Protection: HTTP Basic Auth and Its Trade-offs
If you're protecting a whole directory or a staging site rather than a single link, HTTP Basic Authentication is the standards-based option most web servers support out of the box, defined in RFC 7617 by the IETF. The browser prompts for a username and password, the server checks them against a stored credential, and nothing in that path loads until the check passes. It's blunt, but it's real — the content never reaches the browser unauthenticated.
The catch is that Basic Auth sends the credential with every single request, encoded in Base64. Base64 is not encryption; it's a reversible encoding scheme, which means the password is effectively sent in plain text unless the connection runs over HTTPS. The Mozilla Developer Network's documentation on HTTP authentication is explicit that Basic Auth should only ever be used over TLS. OWASP's authentication guidance goes further and recommends it mainly for internal tooling rather than anything customer-facing, since it has no built-in rate limiting, no password reset flow, and a UI most users find confusing.
A password sent over plain HTTP is a password sent in plain text. Base64 encoding is not encryption — it's reversible by anyone who intercepts the request.
What a Password Prompt Doesn't Stop
A password on a link keeps out people without the password. It does not do several things people assume it does. It won't stop a search engine from attempting to crawl the URL, though Google's Search Central documentation confirms that Googlebot can't authenticate, so a genuinely password-protected page simply won't get indexed — which, for anything meant to be private, is the outcome you want, not a problem to fix.
It also won't stop someone who already has legitimate access from forwarding the link and password together, screenshotting the content, or saving it before the session ends. A password restricts who can open the door; it has nothing to say about what they do once they're inside. If that matters for what you're sharing, you need access logging and expiring links, not just a password — and if you're running your own shortener, that's a reason to look at click analytics and geographic tracking alongside the password itself, so you at least know who opened the link and when.
Finally, a password doesn't fix a link that's wrong in the first place. If you're building a system of branded short links for a business — gated or not — the bigger risk is often ownership: what happens to all those links if you stop paying for the service that issues them. That's a separate problem from password protection, covered in URL Shortener Custom Domain: Access vs. Real Ownership and in Bitly Subscription: What You Pay For and What You Never Own.
Get a Password-Protected Link Without Renting It Monthly
If you only need to gate a handful of links occasionally, almost any shortener with a password feature will do. If password-protected links are part of how your business actually runs — client deliverables, pre-launch pages, gated downloads sent out every week — paying a recurring fee per link or per domain to a hosted shortener adds up fast for something that's fundamentally just a server-side check.
Kortli is a self-hosted link shortener you install once on your own Linux server for a one-time payment, and password protection is one of its built-in link settings, alongside custom branded domains with no per-domain fee, A/B split testing, styled QR codes, and click analytics that stay on your own server instead of a vendor's. It's the option we'd pick if you're tired of recurring fees for features this simple — the honest caveat is that "self-hosted" means you're responsible for your own server, backups, and updates, so check the spec sheet before assuming it's zero-maintenance.
Frequently Asked Questions
Can I password protect a URL without a server?
Not meaningfully. A client-side JavaScript prompt can hide content visually, but the password and the content both ship to the browser, so anyone who views the page source can bypass it. Real protection requires a server or redirect service to check the password before sending any content.
Does HTTP Basic Auth count as real password protection?
Yes, as long as it runs over HTTPS. The server refuses to send any content until it validates the credential, which is genuine access control — just be aware it sends the password with every request and lacks features like rate limiting or password reset.
Will a password-protected URL show up in Google?
No. Google's crawler can't log in, so any page sitting behind a working password check — client-side or server-side — won't get indexed. That's typically the desired outcome for private content, not a bug.
What's the easiest way to password protect a single link I'm sending to a client?
Use a URL shortener that supports password protection at the redirect level, so the check happens before the link forwards anywhere. This is the fastest route that's still real security, without needing to configure your own server.
Is a password enough to protect sensitive files shared by link?
It's a reasonable first layer, but it doesn't stop someone with legitimate access from forwarding the password or saving the content. For genuinely sensitive material, pair the password with link expiration and access logging rather than relying on the password alone.
Sources
- HTTP Authentication Scheme Specification, RFC 7617 | IETF
- HTTP Authentication | MDN Web Docs
- Authentication Cheat Sheet | OWASP
- Introduction to robots.txt and Crawling | Google Search Central
Leave a Reply