Until a few years ago, "share a link" meant "give someone a URL that works forever". Public Google Docs from 2014. S3 buckets with the wrong ACL. Paste-bins from 2011 — still up, still indexed, still findable. Today the default in security-conscious products is the opposite. A link that dies on a timer.
The shift didn’t happen with an announcement. It crept in product by product, default by default. And it’s still creeping.
What changed
The cost of "forever" became visible. Three forces met at roughly the same time, and each amplified the others.
LLM crawlers normalised the idea that anything reachable will be ingested. A link you forgot about doesn’t sit quietly anymore — it gets read, embedded, summarised, and surfaced inside someone else’s answer. The "nobody will ever find this URL" assumption stopped being safe.
Compliance frameworks tightened. GDPR right-to-erasure works poorly when "delete the user’s data" doesn’t reach a shared link that’s still accessible to anyone holding the URL. KVKK’s direction in Turkey moved the same way. SOC 2 auditors started asking specifically about link lifetimes and revocation paths.
User expectation followed. Inside many teams the request shifted from "send me the link" to "send me the expiring one". The long-lived URL became a tell — a hint that the sender hadn’t thought about disclosure.
Where it shows up now
Password managers ship time-bounded "share a secret" links by default and have, over time, shortened the maximum allowable window. Magic-link authentication across nearly every product expires within minutes. File-transfer products that started with permanent links have all migrated to defaults measured in days, not weeks. Documentation tools that still allow permanent public shares have added central revocation as a halfway house.
The category that’s slowest to move is content publishing — "permalink" still means permanent — but everything that touches personal or operational data is converging on expiring by default.
What expiring actually buys you
The window for a leaked link to do damage shrinks from "until someone notices" to "until the timer runs out". For a credentialed system that delta is marginal. For an uncredentialed share — the kind file transfer trades in — it’s the difference between a leak you can survive and a leak you can’t.
Audit logs become cleaner. "This link was alive from day X to day Y" is a fact you can write down. "This link still exists somewhere" is a state you can’t measure.
The mental model improves. The sender starts thinking "I’m sending a thing, for a purpose, for a window" instead of "I’m publishing a URL". That second frame is where almost every "we leaked customer data via a stale link" incident lives.
A long-lived link is a promise you can’t keep. A short-lived link is a contract you can write down.
The trade-offs to name out loud
The recipient has a deadline they didn’t ask for. If they were on holiday when you sent it, the link is dead before they open the email. Every product that defaults to expiring has to make peace with this — usually by surfacing a clear "request a new link" path, sometimes by allowing the sender a one-click extension.
Re-shareable artifacts (final invoices, tax receipts, signed contracts) probably still want a long life. The trend isn’t "everything expires" — it’s "default to expiring, opt out for the things that genuinely need permanence". The distinction matters.
And the user has to learn the new shape. Every team that adopts an expiring-by-default tool has, in its first month, an internal moment where someone says "the link expired before I got to it". That’s the user learning the new contract; it’s not a UX failure.
What this leaves builders with
If your product issues links, the question isn’t "should they expire?" anymore. It’s "what’s the default, what’s the longest opt-in, and how does the recipient ask for an extension when they need one?"
The bar moves a little every year. The links you shipped as "permanent" five years ago are no longer the default — and probably soon won’t be the option.