Password-Protected, Expiring and One-Time Links

A short link doesn't have to be permanent or public. Three controls change that: a password, an expiry date, and a cap on total clicks. Each solves a real problem, and each is easy to over-trust.

Be clear what this is

These controls are access friction, not encryption. A password-protected link keeps a URL out of casual view; it does not protect genuinely sensitive material. Anyone who gets past the gate can copy the destination and share it freely.

Use them for things that are inconvenient to have spread around. Do not use them for anything where a leak would be a real problem — that needs proper access control at the destination, not at the link.

With that framing, they're genuinely useful.

Password-protected links

A visitor hits the short link and gets a password prompt before the redirect.

Good for:

• Client work in progress — a draft, a proof, a preview you don't want indexed or forwarded
• Pricing or terms for a specific customer that you'd rather not have circulating
• Semi-private downloads where you want a small barrier and a record of interest

The practical benefit over sending the raw URL is that the destination never appears anywhere shareable. Forwarding the short link forwards the gate too.

Send the password through a different channel than the link. A message containing both is a single point of failure and defeats the purpose.

Expiring links

The link stops working after a date you set.

Good for:

• Time-limited offers that genuinely end, rather than a "sale" that never closes
• Event registration that should stop when the event does
• Temporary access you'd otherwise have to remember to revoke

That last one is the real value. Access you have to remember to remove is access you will forget to remove. An expiry date is a decision made once, at the moment you have the context, instead of a task you'll never get to.

Point expired links somewhere useful rather than at a dead end — a page explaining the offer ended, with a link to the current one, converts a fraction of that traffic instead of losing all of it.

Click limits and one-time links

The link stops working after a set number of clicks. A limit of one makes it single-use.

Good for:

• Limited-quantity offers — first fifty people, enforced rather than promised
• One-time access where a link should work once and then be spent
• Detecting sharing — if a one-use link is reported as broken by the person you sent it to, it was used somewhere first

Be careful with low limits. Preview crawlers count as requests. Post a one-use link somewhere that generates a preview and the preview may consume it before your recipient taps. For anything genuinely single-use, send it directly rather than posting it, and set the limit with a little headroom.

Combining them

They stack. A link can be password-protected, expire on a date, and cap out at twenty clicks — useful for something like a client proof: gated, time-boxed, and not endlessly redistributable.

The more constraints you add, the more likely a legitimate person hits a wall, so add them deliberately rather than by default.

What none of them do

• They don't hide the destination from anyone who gets through once
• They don't stop the destination being indexed if it's publicly reachable another way
• They don't remove anything already shared — a link that has been out in the world has been seen

For real confidentiality, the protection belongs at the destination: authentication, signed URLs, or access controls on the file itself. These link controls are for reducing casual spread and adding a deadline, which is a genuinely useful thing and not the same thing as security.

Create a protected link — password, expiry and click limits are all free, on every link.