Memorable URLs vs. random IDs: what happens to your shared links a year later

Search your team's Slack for pastebin.com or gist.github.com and open ten links at random. Some fraction will be dead. What is more interesting is the ones that still work: you will have no idea what any of them are until you click.

That second failure gets much less attention than the first, and it is the one the URL format actually controls.

Three ways a shared link rots

They are worth separating, because only one of them is really about expiry:

The paste expired. Someone set a timer, or the service has a default retention policy, and the window closed. This is usually correct behaviour working as designed — you generally want the config file you pasted in March to be gone.

The service changed. Pastebin has repeatedly tightened its policies around anonymous and unlisted pastes. Smaller tools disappear entirely. Nothing about your link is wrong; the other end simply moved.

The link works, and it is useless anyway. This is the quiet one. pastebin.com/xY7k2Ppq is still live, still serving content, and completely opaque. Nobody scanning the channel can tell whether it is the nginx config, the error log, or the seating chart. So nobody clicks, and the link is functionally dead while being technically fine.

Why random IDs fail as references

Random alphanumeric IDs are the obvious implementation. They are trivial to generate, collision-resistant, and cheap to store. They are also bad at the one job a shared URL has after the moment you send it — being a reference that a human can use.

Three specific failures:

• They cannot be spoken. Try reading xY7k2Ppq aloud on a call. You will spell it, capitalisation and all, and the other person will still get it wrong — because l/I/1 and O/0 are indistinguishable in most fonts, and case matters.
• They cannot be retyped. Anything you cannot hold in working memory for the two seconds between glancing at a phone and typing on a laptop has to be copied and pasted, which means the link needs a channel to travel through.
• They cannot be recognised. Two random IDs in a thread look identical at a glance. You cannot tell which is which, which is newer, or whether you have already opened one.

None of this matters in the first thirty seconds after you hit share. All of it matters at every point afterwards — and shared links spend nearly all of their life in "afterwards".

What a memorable slug actually buys

ShareNotes gives you links like sharenotes.dev/blue-fox-42. The payoff is not aesthetic. It is that the link survives leaving the browser:

• You can say "blue fox forty-two" on a call and the other person just types it
• You can write it on a whiteboard and the room can follow along
• You can glance at your phone and retype it on a laptop without a copy channel
• Three of them in a thread are distinguishable from each other a month later

That last point is the one that compounds. A memorable slug does not tell you what is in the note, but it gives your memory something to attach to — and "the blue fox one" is a thing a team can actually say to each other.

Name it yourself when it matters

You can also pick the link yourself, which is the strongest version of the legibility argument — sharenotes.dev/standup-notes is about as easy to communicate as a URL gets. It is worth doing whenever the link has to survive being spoken: a meeting, a call, a whiteboard, a workshop where forty people need to land on the same page at once.

Legible does not mean permanent

A readable link is easier to share, which makes the other half of the problem worth being deliberate about: how long it should exist, and who should be able to open it.

ShareNotes handles those separately from the URL. Notes expire by default — removed 7 days after they were last opened — so shared links do not accumulate forever. You can shorten that to 1 hour or 24 hours, or make a note single-use with delete-after-first-read, which destroys the content the moment it is opened. And a PIN gates access outright, independently of who ends up holding the link.

The actual lesson

Random IDs are not wrong. They are the correct default for machine-to-machine references, where nothing is ever spoken aloud and legibility buys you nothing.

They became the default for human sharing links mostly because they were the easy thing to build, and the cost — links that decay into unclickable noise — shows up months later, long after anyone is evaluating the tool.

If the link is going to be read by a person, in a thread, possibly a year from now, it should be made of words.

Try it: open the editor, paste something, and see what you get. If you would rather drive it from a script, the REST API takes a customSlug and returns the same memorable format by default.