To password protect a URL, you don't edit the link itself — you put a gate in front of what it points to. That gate is either a login prompt baked into the page, a server rule like HTTP Basic Auth, or a link shortener that checks a password before releasing the real destination. The method you pick decides whether that protection is real security or just a speed bump.
TL;DR:
- A URL string can't store a password securely — anything you tape onto it (like
user:pass@domain.com) gets stripped by modern browsers or logged in plain text somewhere.- Real protection means a gate: an HTML prompt (weak), server-level Basic Auth (okay), a CMS login wall (fine but platform-locked), or a shortener with a built-in password check (best for shared links).
- One-time secret links that self-destruct after a single view solve a different problem — sending a password once — not gating a page you'll reuse.
- NIST's password guidance favors length over complexity: a 12+ character passphrase beats an 8-character jumble of symbols.
- A self-hosted shortener with a password field on each link gives you Basic Auth's simplicity without needing server config for every URL you want to protect.
Table of Contents
- A URL Can't Hold a Password — Here's What "Password Protect a URL" Actually Means
- Three Ways to Put a Password in Front of a Link
- How to Make a Password-Protected Page in Plain HTML, and Why It Fails
- Server-Side Gates: Basic Auth and Platform Logins
- One-Time Password Links: Send a Secret Without Sending It Twice
- How Do I Secure My URL Beyond a Password?
- How to Encrypt a Password Online, and What That Phrase Actually Means
- Get Password-Protected Short Links Without Managing a Server
- Frequently Asked Questions
- Sources
A URL Can't Hold a Password — Here's What "Password Protect a URL" Actually Means
A URL is just an address. It tells a browser where to go, not who's allowed to arrive. When people search for how to password protect a URL, they usually mean one of three different things: keep a page from loading for anyone who doesn't know a password, send a link that only works once, or stop a shared short link from being opened by whoever finds it. Each of those needs a different fix, and conflating them is why most guides on this topic feel incomplete — they answer one version of the question and ignore the other two.
The oldest trick — jamming credentials into the address bar as https://username:password@example.com — technically works in some contexts, but it's a dead end. Modern browsers strip or warn against that syntax because it's a known phishing vector, and most chat apps and email clients will mangle the link before your recipient ever clicks it. If you want the mechanics of that approach and where it breaks, the deeper breakdown is in URL Password Protected: What It Means and How to Do It Right.
Three Ways to Put a Password in Front of a Link
Every real method for gating a link falls into one of three categories: client-side (weak), server-side (solid), or shortener-level (fastest to set up). Here's how they stack up against each other.
| Method | Setup effort | Stops | Weak point |
|---|---|---|---|
| Client-side JS password prompt | Minutes, no server access needed | Casual browsing | Password sits in plain text in the page source |
Server Basic Auth (.htaccess or equivalent) |
Low, but needs server access | Anyone without credentials | One password for everyone; no expiry date |
| CMS/plugin login wall | Medium, platform-dependent | Search engines, random visitors | Ties the protected content to that one platform |
| Self-hosted shortener with a password field | Low, once installed | Anyone without the password | You're responsible for the server it runs on |
| One-time secret link (burns after reading) | Minutes | Interception of the message itself | Useless if the recipient loses the message before opening it |
Pro Tip: If you're tempted to use Basic Auth with credentials embedded in the URL for convenience, don't. Chrome and Firefox both suppress or warn on the user:pass@ syntax in the address bar precisely because it's been abused in phishing links, and copy-pasting that URL into Slack or an email will often get the credentials silently stripped — so the link arrives looking valid but broken.
How to Make a Password-Protected Page in Plain HTML, and Why It Fails
You can gate a page with nothing but HTML and JavaScript: a form field checks what the visitor types against a stored string, and if it matches, a script reveals the content or redirects them forward. It takes fifteen minutes to build and feels like it works.
It doesn't hold up under inspection. Anyone who opens the browser's developer tools can read the password directly out of the page's source code, because client-side JavaScript has to run in the visitor's browser — which means the logic, and the password it's checking against, is sitting right there in plain text. This method stops nobody who knows to press F12. If you're set on a pure HTML/JS approach anyway, the specific pitfalls and a couple of ways to make it marginally less bad are covered in Password Protect a Link in HTML: What Actually Works.
Server-Side Gates: Basic Auth and Platform Logins
HTTP Basic Authentication, defined in RFC 7617, moves the password check off the page and onto the server. The browser pops up its own native login dialog before the page ever loads, and the credentials never appear in the HTML. That's a real improvement — it's genuine access control rather than a cosmetic one.
The trade-off is flexibility. Basic Auth gives you one username and password pair per protected directory, with no built-in expiry, no "send this to three people with three different passwords" option, and no record of who actually logged in beyond raw server logs. It's the right call for gating a staging site from search engines and casual visitors. It's the wrong call if you need to hand out different access to different people or revoke one person's access without resetting it for everyone.
One-Time Password Links: Send a Secret Without Sending It Twice
Sometimes "password protect a URL" isn't about a page at all — it's about safely handing someone a password, API key, or Wi-Fi code without it sitting in a Slack thread or an email forever. The standard pattern for this is a one-time secret link: you paste the sensitive text into a tool, it generates a link, and that link displays the content exactly once before it's gone for good.
This is a different job than gating a page you'll reuse. A one-time link is built to be consumed and destroyed; a password-protected page is built to be checked against repeatedly. If you need the former, look for a tool with configurable expiry (views remaining, or a time limit, or both) rather than one that just deletes after 24 hours regardless of whether anyone opened it.
How Do I Secure My URL Beyond a Password?
A password is one layer. On its own, it doesn't protect against a link getting indexed by a search engine before you add the gate, against the destination page being served over plain HTTP where the password is visible to anyone on the same network, or against the password itself being weak enough to guess in a handful of tries.
Three things matter more than people expect: serve the protected page over HTTPS so the password isn't sent in plain text; add a noindex meta tag or robots rule so search engines don't crawl and cache the "protected" content before you lock it down; and set an expiry wherever the tool allows it, so a link that's been shared once doesn't stay valid forever. If you're protecting a link specifically because you don't control the domain it lives on, URL Shortener Custom Domain: Access vs. Real Ownership covers the related problem of actually owning the infrastructure your links depend on.
Passwords People Actually Use, and What "Strong" Really Means
If you're asking what the top 7 passwords are, you're really asking which ones to avoid, because the same handful show up near the top of breach and leak lists year after year: 123456, 123456789, qwerty, password, 12345, qwerty123, and 1234567. NordPass's annual ranking of the world's most common passwords has shown variations on this same short list for years running — they're not just common, they're the first guesses in any automated attack.
NordPass's annual ranking has put "123456" at or near the top of the world's most common passwords for well over a decade.
A 12-character strong password isn't 12 random symbols — it's length combined with unpredictability. NIST's Digital Identity Guidelines (SP 800-63B) explicitly favor length over forced complexity, recommending passphrases of unrelated words over short strings crammed with special characters. A string like horse-battery-signal-42 is both easier to remember and harder to brute-force than P@ssw0rd!, because the attacker has to search a much larger space of possibilities, not just guess which symbol replaced which letter.
How to Encrypt a Password Online, and What That Phrase Actually Means
"Encrypt my password online" usually means one of two different things, and mixing them up is a real risk. If you mean "turn my password into something unreadable before storing it," what you actually want is hashing, not encryption — encryption can be reversed with a key, hashing is designed to be one-way. The OWASP Password Storage Cheat Sheet recommends algorithms purpose-built for this, like bcrypt or Argon2, specifically because they're slow on purpose — that slowness is what makes brute-forcing a stolen password database impractical.
If you mean "I want to send a password to someone without it sitting in plain text in transit," that's a transport problem, and a one-time secret link or an end-to-end encrypted message is the right tool, not a generic "encrypt text online" site. Be wary of random web tools that ask you to paste a real password into a text box and hit "encrypt" — you have no way to verify what that site logs, caches, or does with the plaintext before it ever reaches the encryption step.
Get Password-Protected Short Links Without Managing a Server
If what you actually need is to share a link — a file, a landing page, a client preview — with a password in front of it, but you don't want to build Basic Auth rules or trust your password to a browser extension, that's the exact gap Kortli fills. It's a self-hosted link shortener you install once on your own Linux server for a one-time license fee, and every short link it creates can carry its own password, independent of the others — no shared Basic Auth credential, no per-link server config.
The honest limit: you still need a server to run it on, and "self-hosted" means you're the one keeping it patched. If zero server maintenance matters more to you than owning your links, a hosted option might suit you better — Sites Like Bitly: 10 Alternatives Worth Your Time in 2026 covers that trade-off directly, and Shorten a URL With Your Own Domain: The Real Options walks through what "owning" a short link actually requires.
Frequently Asked Questions
How do I secure my URL?
Serve it over HTTPS so nothing in transit is readable in plain text, add a password gate if the content shouldn't be public, and use a noindex tag so search engines don't crawl and cache it before you lock it down. Set an expiry wherever your tool allows it so an old shared link doesn't stay valid indefinitely.
What are the top 7 passwords?
Lists like NordPass's annual breach-based ranking consistently show the same weak passwords at the top: 123456, 123456789, qwerty, password, 12345, qwerty123, and 1234567. They rank high because they're the first guesses in any automated cracking attempt, not because they're rare mistakes.
How can I encrypt my password online?
If you're storing a password, you want one-way hashing (bcrypt or Argon2, per OWASP's guidance), not reversible encryption. If you're sending a password to someone else, use a one-time secret link or an end-to-end encrypted message rather than pasting it into a generic online "encrypt text" tool whose logging practices you can't verify.
What is a 12-character strong password?
It's a 12-plus character string built from unpredictability, not just symbol-stuffing — NIST's guidelines favor length and passphrases of unrelated words over short strings crammed with special characters. A phrase like "horse-battery-signal-42" is both easier to remember and harder to brute-force than a short password with swapped symbols.
Is putting a username and password directly in a URL safe?
No. Modern browsers strip or warn against the user:pass@domain.com syntax because it's a known phishing technique, and many chat and email clients will mangle the link before it reaches the recipient. Use server-side Basic Auth or a shortener with a password field instead.
What's the difference between a password-protected link and a one-time secret link?
A password-protected link is meant to be reused — anyone with the password can open it repeatedly. A one-time secret link is meant to be consumed once and then destroyed, which is the right tool for sending a password or key rather than gating a page.
Sources
- NIST Special Publication 800-63B, Digital Identity Guidelines | National Institute of Standards and Technology
- Password Storage Cheat Sheet | OWASP
- Most Common Passwords List | NordPass
- RFC 7617: The 'Basic' HTTP Authentication Scheme | IETF Datatracker
Leave a Reply