Why Deleted Short-Link Aliases Shouldn't Be Recycled

Handing a retired short link code to someone new looks like tidy housekeeping. In practice it gives a stranger traffic that was meant for somebody else. Here is how that goes wrong, and why LinkMint never reuses a code.

25 February 2026 · 8 min read · updated 10 October 2026

Here is a decision that looks like housekeeping and is really about security. A short link stops being used, because it was deleted, it expired, or its account was closed. What happens to the alias, the part after the slash?

The obvious answer is that it becomes available again. The link is gone, the name is free, and holding on to strings nobody uses seems wasteful. Plenty of systems that manage names work that way, and for most of them it is fine.

For short links it is not fine. A short link is a name whose whole purpose is to be copied, printed and saved by people its creator has no contact with. Those copies do not disappear when the link does.

The problem, concretely

Picture a small business on a link service that lets people choose their own aliases and frees them on deletion. They shorten their payment page to something memorable, the kind of thing you can say over the phone.

The link

short.example/pay  →  invoices.thebusiness.example

It goes on invoices. It goes in the email footer. Someone writes it on a compliments slip. It is forwarded, screenshotted and saved in notes apps.

Eighteen months later the business changes payment provider and deletes the old link. Entirely reasonable: the old destination no longer exists, so the link was broken anyway.

If the alias is released immediately, anyone can now claim /pay. The traffic does not stop because the link was deleted. Old invoices sit in filing systems. Old emails sit in inboxes. Somebody is going to type that address next Tuesday because they have paid that way for a year and a half.

Whoever claims the alias inherits all of it: a steady stream of people who arrive expecting to pay a business they trust, at an address that business gave them.

Generated codes do not make recycling safe

It is tempting to think the problem only applies to chosen aliases like /pay. If codes are random strings, nobody can target a particular one. That reduces the risk but does not remove it.

Accidental inheritance. If a freed code goes back into the pool, an ordinary new user may be given it. Their link then receives visits from old printed material and old messages, aimed at someone else. At best that is confusing; at worst it sends a stranger's customers to an unrelated or unsuitable page.
Deliberate farming. Someone who wants a particular freed code can keep creating links until the random draw hands it to them. Rate limits make this slower, but the attempt costs the attacker very little.
Leaked old content. A code that once pointed at a private document, shared with a few colleagues, may later point at something public, or the other way round. The people holding the old link have no way of noticing the change.

The underlying point is the same in every case. A short link's audience is defined by everywhere the address has been copied, not by who owns it today. Reassigning the address reassigns the audience.

Why this is worse than an expiring domain

Domain names have a similar problem, and the domain system treats it seriously. Registrations have public expiry dates, renewal reminders and grace periods before a lapsed name can be registered by someone else. The whole system assumes that letting a name go is a significant event.

A short link alias, in many tools, has none of that. It is a row in a table. Removing it is one click, and if the tool recycles, the name is available the moment the row is gone.

It is also easier to watch. A shared short domain has a predictable space of popular words. Anyone can check /pay, /invoice, /donate, /login and a few thousand others on a schedule and claim whichever becomes free. It needs no special access, only patience and a short script.

And the person who inherits a recycled alias does not have to build anything convincing. The trust is already there: the address came from the original owner, appeared on their paperwork and behaves exactly as it always did, right up to the page it lands on.

Printed things make it permanent

If a link only ever lived in a social profile you control, retiring it is low risk. You change the profile and the old link stops being visible.

Physical material does not work like that. A QR code on packaging is in a warehouse. A poster stays in a bus shelter until somebody takes it down. A sticker stays on a shop window until it peels. A conference programme is in thousands of tote bags. QR codes are static, so a code that contains a short link contains it forever. None of it can be recalled, and all of it keeps sending people to that address long after the link's creator has stopped thinking about it.

The usual fix: a cooldown

Services that allow deletion and want to release names eventually often use a reservation period. When a link is deleted, its alias is recorded with a release date, and nobody can claim it until that date passes. If you are building or evaluating such a system, two details matter more than the length of the period.

The reservation should apply to everyone

Including the person who deleted the link. That feels unfriendly, because deleting and recreating is a normal way to fix a mistake. But an exception for the original owner is an exception an attacker will look for. Accounts are transferred, recovered and occasionally compromised, and "who counts as the original owner" turns out to be a hard question. A rule with no exceptions cannot be argued around.

The reservation should be written before the link is removed

If the link is removed first and the reservation is written second, there is a short window in which the alias is free and nothing stops a claim. Someone polling in a loop can land in it. Writing the reservation first, or doing both in one database transaction, closes the gap. It matters most when an account is closed and many aliases are released at once.

Even done well, a cooldown is a deterrent rather than a wall. It removes the cheap, automated, opportunistic version of the problem. It does nothing about printed material that is still in circulation when the period ends, and for a high value alias a patient person will simply wait.

The stronger fix: never reuse a code

The only complete answer is not to recycle at all. Once a code has been used, it is retired permanently, whatever happens to the link it belonged to.

This has a cost, and it is worth being honest about it. Every code ever issued stays out of circulation, so the pool of available codes only shrinks. For a service where people choose memorable words, that is a real loss: the good names run out. For a service that generates random codes, it barely matters, because the space of possible codes is far larger than the number ever issued, and every new link is simply checked against the existing ones before it is saved.

How LinkMint handles it

LinkMint takes the strongest position available, partly because of how the rest of it works.

Codes are generated, five characters from an alphabet with no look-alike characters. Nobody can choose a code, so there is no /pay to watch for.
Codes are never recycled. A code that has been issued belongs to that link for good.
Links never expire. There is no expiry setting and no clean up job that retires old links.
Links cannot be deleted by the person who made them. Without accounts there is no way to prove who made a link, so there is no delete button to misuse.
Moderators can disable a link after an abuse review. A disabled link shows a notice page and redirects nowhere. Its code stays retired.

That last point is the one that most often surprises people. Disabling a link is not the same as freeing it. If a code pointed at a phishing page and was disabled, the old messages containing it are still out there, and the right outcome for anyone who follows one is a clear notice, not a fresh redirect to whatever someone else created later.

What happens to a code in different situations
Situation	On a service that recycles	On LinkMint
Owner deletes the link	Code may go to someone else	Not possible; links cannot be deleted
Link reaches an expiry date	Code may go to someone else	Not possible; links never expire
Link disabled after abuse review	Varies	Notice page shown; code never reused
Years pass with no visits	Code may be cleaned up and reissued	Link keeps working as created

The reasonable objections

Not being able to delete your own link is a genuine limitation. If you shorten the wrong address, that link stays in existence pointing at the wrong address. The practical answer is to check the destination before creating the link, using the plus sign preview on the result if you want to be sure, and simply not to share a link you got wrong. An unshared link with a forgotten code harms nobody. If a link points at something harmful, anyone can report it at /report without an account, and it can be disabled after review.

The other objection is that permanence is a commitment: a service that promises never to recycle and never to expire has to keep that promise. That is true, and it is the right commitment for something people print on objects they cannot recall.

What to ask any link tool

This rarely appears on a feature list, which is a shame, because the answer tells you how seriously a tool takes the fact that its links end up on physical things.

When a link is deleted or expires, can its alias ever be given to someone else?
If so, after how long, and does the same rule apply to the original owner?
What happens to all my aliases if my account is closed or stops being paid for?
If a link is disabled for abuse, what do visitors see, and is the alias ever released?
Are generated codes drawn from a pool that includes previously used codes?

A tool that has thought about this will have answers ready. A tool that has not will treat these as odd questions, and that is an answer too.