Password Protect a Link in HTML: What Actually Works

A padlock sitting on a bundle of network cables next to a closed laptop.

Written by

fastreader@pm.me

in

To password protect a link in HTML, you write client-side JavaScript that checks a password before revealing or redirecting to the real URL — but that password sits in plain text in your page's source code, readable by anyone who hits Ctrl+U. The distinction that matters is client-side versus server-side: HTML/JS gating stops casual clicks, while real protection requires a server checking the password before the link ever loads.

TL;DR:

  • Plain HTML/JavaScript password prompts live in the page's source code — they stop casual visitors, not anyone who checks View Source.
  • <input type="password"> only masks characters on screen; toggling it to type="text" is how you build a show/hide eye icon.
  • "Encrypting" a URL usually means HTTPS (transport security) or Base64 (encoding, not security) — neither hides a destination from someone who already has the link.
  • Client-side encrypted pages, where the password is the decryption key, are a real improvement but can still be brute-forced offline if someone keeps a copy of the file.
  • For a link you actually need to gate and track, server-side checking — via .htaccess, a backend app, or a self-hosted shortener — is the only version that holds.

Table of Contents

A padlock placed beside a curtain partially drawn over a window.

Every HTML method for "password protecting" a link does one of two things: it hides the destination until someone types the right string, or it checks a password before a server hands over the real content. Those sound similar. They are not. Hiding happens in the browser, where the visitor's machine holds all the code, including your password, your obfuscation, and your "secret" logic. Checking happens on a server you control, where the visitor never sees anything until they prove they should.

If you're protecting a link to an internal memo from search engines and casual link-sharing, client-side hiding is fine — it raises the bar just enough. If you're protecting a client's financial report, a paid course module, or anything with real stakes, you need the server-side version, full stop. Everything below is organized around that line.

Hands typing on a keyboard with a small padlock-shaped keychain next to them.

The fastest way to put a password on a link is a JavaScript prompt that intercepts the click, compares the input to a stored string, and redirects only on a match:

<a href="#" onclick="return checkPassword()">View the report</a>

<script>
function checkPassword() {
  const entered = prompt("Enter the password:");
  if (entered === "quarterly2025") {
    window.location.href = "https://example.com/real-report";
    return false;
  }
  alert("Incorrect password.");
  return false;
}
</script>

This is a complete, working answer to "how do I put a password on a link" — it will run in any browser, needs no server, and takes about five minutes to set up. It also fails the moment anyone opens the page's source, because the password quarterly2025 and the real URL are both sitting right there in plain text.

Hide and Show a Password in HTML: The Toggle Pattern

Hands shining a flashlight on a padlock to inspect it closely.

The "hide and show a password" question usually isn't about the link password itself — it's about the input field visitors type into. HTML's password input type, as documented by MDN Web Docs, masks every character by default so shoulder-surfers can't read it. Toggling visibility is just a matter of swapping the type attribute with JavaScript:

<input type="password" id="pw" placeholder="Password">
<button type="button" onclick="toggleVisibility()">Show</button>

<script>
function toggleVisibility() {
  const field = document.getElementById('pw');
  field.type = field.type === 'password' ? 'text' : 'password';
}
</script>

A CSS-only eye icon usually pairs an ::after pseudo-element or an SVG button with this same type-swap — the visual polish is CSS, but the actual show/hide behavior is always JavaScript, because CSS alone cannot change an HTML attribute.

Pro Tip: If you're building this toggle for a real login form, don't rely on autocomplete="off" to stop browsers from offering to save the password — modern browsers mostly ignore that attribute for password fields on purpose. If you don't want a save prompt, you have to change the field's name and id to something non-standard, which is a trade-off against autofill convenience, not a real security control either way.

Why Client-Side Passwords Fail the Moment Someone Opens DevTools

Here's the part every tutorial glosses over: a password check that runs in the visitor's browser has to ship the correct answer to the visitor's browser. There's no way around this. Even if you hash the password with JavaScript before comparing it, the hash itself is sitting in your source, and offline brute-forcing a hash with no rate limit is fast.

View Source. That's the entire attack. No tools required.

OWASP's guidance on broken access control — the single most common vulnerability class in its Top 10 — makes the same point in sharper terms: access-control decisions enforced only on the client are not access control at all, because the client is fully in the hands of whoever is using it. A visitor doesn't need to be a hacker to defeat an HTML password prompt. They need a keyboard shortcut and thirty seconds. For a closer look at what a password gate is actually meant to stop, Password Protected Links: What They Lock and How to Build One breaks down the specific threats each method does and doesn't address.

Can You Actually Encrypt a URL? Three Different Things Get Called "Encryption"

"Encrypt a URL link" usually means one of three unrelated things, and mixing them up is where most DIY password protection goes wrong.

  • HTTPS. This encrypts the connection between a visitor's browser and your server, hiding the page's content from anyone intercepting the traffic in transit. It does nothing to hide the destination from someone who already has the link, and it's table stakes now — Google has confirmed HTTPS as a ranking signal since 2014, so a link without it is already a liability before you've thought about passwords.
  • Base64 encoding. You'll see links or parameters that look scrambled because they're Base64-encoded, as defined in IETF RFC 4648. This is not encryption — it's reversible with one line of code and no key at all. Never mistake an encoded link for a protected one.
  • Client-side page encryption. Some open-source tools encrypt an entire static HTML page using the visitor's password as the decryption key, so the server genuinely never sees the password and the page is unreadable without it. This is real cryptography, and it's a meaningful step up from a JavaScript prompt — but anyone who downloads a copy of the encrypted file can try to brute-force it offline, forever, with no lockout and no logging. A short or common password undoes the whole scheme eventually.

None of these three "encrypts the URL" in the sense most people mean when they ask the question — hiding a destination from someone who doesn't have the password yet. That requires checking the password before the destination is ever sent, which is a server's job, not a browser's.

Comparing Your Options at a Glance

Method Where the password lives Defeated by Setup time Good for
HTML/JS prompt Plain text in page source View Source ~5 minutes Keeping casual visitors out, nothing sensitive
Client-side encrypted page Password is the decryption key Offline brute force of weak passwords 15–30 minutes Static pages, low-stakes content
Server Basic Auth (.htaccess) On the server Nothing, if configured right — but one shared password, no per-user tracking ~10 minutes with server access Internal pages, staging sites
Self-hosted link shortener with a password gate On your own server, checked pre-redirect Guessing the actual password ~10 minutes to install Branded links you need to gate and track

When HTML Isn't Enough: Server-Side Password Gates That Actually Hold

If the link protects anything with real value — a paid download, a client deliverable, a pre-launch page — the password check has to happen before your server sends a response, not after the browser already has one. Three practical routes get you there:

  • .htaccess Basic Auth. If you're on Apache, a few lines in a .htaccess file password-protect a whole directory server-side, with no code to write. It's blunt — one password for everyone, no analytics — but it's genuinely secure.
  • A small backend script. PHP, Node, or Python can check a password against a session before serving a redirect or a file. This is what most "password protect a static HTML page" tutorials are quietly describing once you get past the client-side examples.
  • A self-hosted link shortener with password gating built in. If what you actually have is a short link you're sharing — in an email, a QR code, a social post — rather than a whole page, a shortener that checks the password on its own server before redirecting is the more direct fix. It also gives you click data the first two options don't. Open Source Link Shortener: The Real Trade-Offs, Compared walks through self-hosted options if you want to run this yourself, and Shorten a URL With Your Own Domain: The Real Options covers the domain side of the same setup.

If you've read this far because you want the result — a link that asks for a password before it redirects, with no prompt to reverse-engineer and no .htaccess file to babysit — that's exactly what Kortli does, built into a self-hosted link shortener you run on your own Linux server for a one-time payment instead of a subscription. You set a password on any short link from the dashboard, it's checked server-side before the redirect fires, and you get click and geographic data on your own infrastructure instead of handing it to someone else's.

It's a one-time license, not a recurring fee, and it runs on a server you control — which also means the caveat: you're responsible for keeping that server patched and online, the way you would any self-hosted tool. If you'd rather never touch a server, a hosted service is the better fit. If you're tired of paying monthly for something this simple, check the spec sheet and see if it fits.

Frequently Asked Questions

You either write a JavaScript check that runs before a redirect (fast, but visible in page source) or use a server-side gate — like .htaccess, a backend script, or a link shortener with built-in password protection — that verifies the password before the destination is ever sent. The server-side route is the only one that can't be bypassed by viewing the page's source code.

How can I password protect an HTML webpage?

For a single static page, a client-side encryption tool can encrypt the whole file using the password as the decryption key, which is real protection against casual access. For anything sensitive, host the page behind server-side authentication, such as Apache's Basic Auth or a small backend script that checks a session before serving the file.

In most cases you don't need to "encrypt" the URL itself — you need HTTPS protecting the connection, which is now standard and expected by browsers and search engines alike. Base64-encoding a URL just scrambles its appearance without adding any real security, since it's reversible with no key required.

How can I hide and show a password in HTML?

Use an <input type="password"> field, which masks characters by default, and toggle its type attribute to text with a few lines of JavaScript when the user clicks a show/hide button. CSS can style the icon or button, but the actual masking and unmasking is controlled through the HTML attribute, not CSS alone.

A password-protected link checks the password before deciding where to send the visitor at all, which is how most link shorteners with this feature work. A password-protected page lets the visitor reach the page's address but blocks the content itself until they authenticate, which is the more common pattern for full websites or documents.

Can someone bypass an HTML password prompt just by viewing the page source?

Yes, if the password and the real destination are written directly into the HTML or JavaScript, anyone can read both with the browser's View Source or Developer Tools. This is why security guidance from organizations like OWASP treats client-side-only checks as no protection at all for anything that actually matters.

Sources

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *