For those looking for more options, Dub[1] is a matured open-source[2] link shortener with Analytics.
For not-so-large volumes of links, say for friends-family, and the occasional public links, you can run something off Github Pages[3] with their built-in Jekyll + Redirect-From Plugin[4]. If you do not want to, you do not even need to have the code run locally, just edit on Github. I run one to easily share links for the family and relatives (photos, that document link, along with the Rick-Roll Video).
Tip: If one wants to run an indie or personal or family/friends shortlink for easy sharing, try to have it on your own domain. This allowed me to moved between tools that powers it.
At the scale of their SaaS service this makes sense, but for a typical user a Sqlite database (or as you did a Cloudflare Workers KV) is really all you need
Or should this be more specific in that you shouldn't shorten URLs using the provider's domain name, but bring your own domain. So if the provider goes away, you can in some way migrate the links.
That's why I set up my own thing.
I don't care about analytics at all, so I just wrote a simple build system doto generate some very basic HTML redirects.
As a hypertext purist, I used to think this. But working for a large organization, shortlinks can be an invaluable way to actually maintain the integrity of links that have been deployed to unrevisable media (emails, print, pdfs, etc).
If a resource has been relocated off of a host/url, often part of that situation is that we don't have immediate access to implement a redirect from that host to the resource's new location.
Now I see a shortlink manager as a centralized redirect manager, which is so much more rational and stable than creating a tangle of redirect config across dozens of hosts or hundreds of content applications.
The caveat is that you don't need to use a 3rd party domain or service, you should definitely at least use your own domain. You also don't need to make them unreadable hashes, they can actually be more human-friendly.
Last big project at my old job was for an appointment notification service. In addition to making SMS messages longer and thus costing us more, counterintuitively the unshortened URLs got flagged as spam by automated systems and end users more than shortened. However, you can’t use bitly or other free/public shorteners; use one hosted on your own domain. I used shlink https://shlink.io/
Another advantage is that the redirect address of the sent link can be modified. If there are changes in operational requirements, the landing page address can be adjusted in a timely manner
There are many, perfectly valid non-marketing use cases for link shorteners. We send SMS's to people with a link in them. We shorten them so SMS is less annoying to read. Also, we print links in terminal sessions, same thing.
When it comes from a vendor you signed up for and you configured the service to send you SMS's on certain events. For us that is when a site or app goes down. Think Pagerduty without the pager.
In some cases the size of the URL matters. No matter if that's a human who doesn't want their reading flow interrupted by a link that covers three lines in mobile view (hence why linkedin or printed magazines operate shorteners), a user who legitimately types in links in cases where copy-paste isn't an obvious solution (e.g. typing a link you see on a stranger's device, like a party game or the link on a bluescreen, or again links in print), or you want to create a QR code that's readable from a distance and doesn't have 8 alignment squares.
I would get behind the argument that there aren't good use cases for 3rd party url shorteners. A url shortener should preferably be operated by the target website (like youtu.be), and failing that be operated by the originator of the link (linked.in, t.co, time.com).
How does one block spam URLs using a link shortener? I've only ever seen shorteners used to bypass blocks
And for tracking, as you say. This would be understandable when the person sharing the link doesn't run the web server and can't simply look in access logs to find click rates, but then what they end up doing is giving everyone a unique link using marketing software and it can be tracked exactly who opened which link at what time on an individual level, as if that's necessary
The tracking is the real reason for it in the majority of cases it is used IMHO. The other rationalizations are things that humans do to help convince themselves that there's more nuance so what they're doing isn't nearly as naked self-interest as it seems. I'm thinking of Twitter's shortener for example. Self-hosted/small stuff used for SMS reasons for example (on a domain owned by the same org) are a different bag.
People who track link usage use links to a tracking service which redirects to the target, or embeds tracking metadata in the URL. You could have a tracker which produces shortened links, or try to hide your tracking metadata by putting the already tracked link through a shortener, but that's all without consequence as a shortened URL looks no less suspicious than a URL with kilobytes of metadata. I suppose some trackers might try to (mis)brand themselves more positively as shorteners though.
Nothing about a shortener helps you block spam URLs - quite the contrary, they tend to be used to hide spam URLs.
The main legitimate use-case I can think of for shortened URLs are those used in advertisements or manuals, where the user might need to type it manually.
> Link analytics is explicitly one of the stated use cases on Bitly, and you can even add UTM parameters automatically
This is against not in favour of your argument - it's a case of Bitly enabling users to still use other systems for tracking (UTM) while using a link shortener (as said by person you replied to), not evidence of tracking being the purpose of the link shortener.
Bitly does have their own basic analytics built in, so some people do use it for tracking, but that's still a secondary function for people who don't care enough to set up independent tracking. It's not a sale pitch of "if tracking is what you want, link shortening is the solution".
And the t.co example isn't actually useful for spam prevention, if Twitter decides that a certain URL is considered spam they can just as easily remove that link from any tweets trying to use it as they can disable a t.co. Meanwhile the t.co does add friction for users seeing whether the destination URL looks likely to be spam. I don't think I've ever heard anyone before argue that link shorteners are a good thing for fighting spam, only either bad or at best neutral.
From a scale perspective it also seems a lot easier to remove one redirect from happening vs. finding every Tweet that contains a certain url you want to remove.
> Additionally, we now use our link shortener (t.co) to analyze whether a tweeted link leads to malware or malicious content. This helps us prevent users from visiting malicious links and helps us shut down hundreds of thousands of abusive accounts.
You're misunderstanding the bit of that blog post that you've quoted - it only says that starting to analyse t.co links for malicious content is a good thing for reducing malicious content. It says nothing about whether that job is easier than if they started doing the analysing without having a link shortening system in place. And in fact it goes to show that spam prevention wasn't a motivating factor in their creating t.co shortener in the first place, since they only started analysing for malicious links later than they started shortening links.
It is possible that their task was made easier by having the t.co system in place - impossible to know without understanding engineering details of how Twitter and t.co work - but it's not a claim they've made publicly, nor a reason for their deciding to use shortened links.
I think we have different ideas of "control," because in your scenario it sounds to me like Netlify controls at least some of it. Should Netlify go away, you still own the domain so there's a path to migration, but at that point I think you'll realize that 99% of the code that was doing the work was Netlify's, so you'll have some major work to do.
Of course if it's just a personal link shortener then that's perfectly fine, but if this was a "production" thing I'd be concerned about it
