Expiring links and click limits: when a short link should stop working
Most short links are immortal by default, which is the wrong default for a one-time invite, a password reset handoff, a webinar seat, or a document you only meant one person to open. Expiry dates and click caps are a small feature with real security value, and a few sharp edges worth knowing before you rely on them.
Short links are immortal by default. You create one, it resolves, and it keeps resolving until somebody deletes the row. For most links that is correct behavior. For a surprising number of the links people actually send each other, it is the wrong default.
The invite to a shared folder. The link to the draft. The URL that lets a contractor grab a file for one afternoon. The webinar registration that closes on Friday. Each of those has a natural end, and leaving the link alive past that point is not convenience, it is an unattended door.
Two stop conditions, two different jobs
An expiry date is time-bound. It fits things with a schedule: an event page, a seasonal offer, a temporary redirect during a migration, a link on a slide you will present once. Set the date and the link stops resolving after it, whether it was used or not.
A click limit is use-bound. It fits things meant for a known, small number of opens: a one-time handoff, a download you intend one person to make, a link posted where you want to cap exposure. When the counter hits the cap the link stops forwarding.
They compose. A cap of five clicks with a 48 hour expiry says "a handful of people, this weekend only", which is closer to how people actually share things than "forever, anyone".
Why this is a security feature and not a gimmick
URLs leak. Not dramatically, just constantly. They get forwarded, pasted into group chats, saved into browser sync, captured in screenshots with the address bar visible, indexed when someone posts them on a public page, and recorded by whatever mail scanner or security gateway touched the message in transit. Every one of those copies stays valid for as long as the link does.
Expiry does not stop the leak. It bounds the damage window. A link that stopped working two weeks ago is worth nothing to whoever found it in an archived chat, and that is a meaningful reduction in exposure for a feature you configure once.
It also matters what an expired link says. A dead link that still shows the destination URL on its error page has leaked the thing you were protecting. When a forwrd.us link expires, the slug stops resolving and the destination is not shown, which is the behavior to look for in any service offering this.
The sharp edges
- Automated fetches eat click budgets. Chat platforms unfurl links by fetching them. Mail security products detonate them in a sandbox. Some of those fetches resolve the redirect and count as a click. A cap of one can be spent before your recipient taps anything. Leave headroom.
- Expiry is not authorization. Anyone with the URL can use it inside the window. This is the mistake that turns a feature into a false sense of safety. If only one named person should see the content, the destination needs a login, a signed token, or a per-recipient URL. The redirect layer cannot supply what the destination does not enforce.
- Clocks and time zones. Expiry is evaluated in UTC on the server. "Ends Friday" means a specific instant, not the end of the reader's Friday, wherever they are.
- Caching. A permanent redirect can be cached by browsers and intermediaries, so a client that already followed the link may not come back to the server to be told it is over. Expiring links should be issued as temporary redirects for exactly this reason.
- Self-inflicted link rot. Expiry on anything printed, published, or cited is the failure mode described in the link rot piece, except you did it to yourself on purpose.
Sensible defaults
- One-time file handoff: click limit of 3, expiry in 24 to 72 hours. The headroom absorbs previews and scanners.
- Event or campaign link: expiry set to the day after the event, no click cap.
- Temporary redirect during a migration: expiry at the end of the cutover window, so a forgotten redirect does not outlive the reason for it.
- Link posted publicly: no expiry, no cap. If it is public and permanent, treat it as public and permanent.
- Anything printed or cited: no expiry, and preferably no shortener at all.
How it works on Forwrd
Expiry dates, click limits, and custom slugs need ownership, so they require an account. Everything else on the site does not: anonymous shortening stays the default, with no email address and no verification step. Once you have an account you can set both conditions when creating a link, in bulk, or through the API, and you can see how many of the allowed clicks have been used.
The statistics stay deliberately coarse. A click increments a counter and, for account-owned links, a per-day total. There is no visitor identifier, so a click cap is a quota and not a record of who used it. That is a real limitation if you wanted to know which recipient opened your link, and we are not planning to add it. The reasoning is in what forwrd.us logs when someone clicks.
Frequently asked
What is an expiring short link?
It is a short link with a stop condition attached. Instead of resolving forever, it stops forwarding after a date and time you set, after a number of clicks, or both. Once the condition is met the slug returns a plain 'this link is no longer active' page instead of a redirect, and the destination is not disclosed.
Is an expiring link the same as password protection?
No, and this matters. Expiry limits how long a link works; it does nothing about who uses it during that window. Anyone holding the URL before it expires can open it. If the content behind the link must only be seen by one specific person, the access control has to live on the destination, not on the redirect.
Do click limits count preview fetches and bots?
That depends on the implementation, and it is the sharpest edge in the feature. Chat apps, mail scanners, and security gateways fetch links automatically, so a cap of one can be consumed before the human ever taps. Treat a click cap as a blunt safety valve, not an exact quota, and leave headroom when the link travels through email or a messaging platform.
When should a link not expire?
Anything published, printed, cited, or embedded in a document you cannot recall. Expiry on a permanent artifact is self-inflicted link rot. Use it for temporary handoffs and coordination, and use plain durable links for anything that has to work in three years.
Related reading
QR codes are short links printed as pixels
A QR code is not a technology for trust. It is a machine-readable string with no human-readable preview, which is exactly why quishing works on people who would never click the same URL in an email. Here is what a QR code actually encodes, why the phone camera layer is where the risk lives, and how to publish one without turning it into a permanent dependency on a company staying alive.
13 min readHow to check where a short link goes before you open it
The whole function of a short link is that it hides the destination, so the usual advice to read the URL before clicking does not apply. There are still reliable ways to resolve one without loading the page. Here is what works, what does not, and why an unfurled preview in a chat app is not the same as knowing where a link points.
11 min readWhat forwrd.us logs when someone clicks your link
Every shortener sits in the path of every click, which makes it an analytics checkpoint whether it advertises itself as one or not. Rather than write another piece about other people's logging, here is ours: what a click writes to our database, what it does not, what our hosting layer sees before our code runs, how long any of it lives, and which parts we cannot promise away.
12 min read