A URL shortener is safe in roughly the way a phone number is safe: it's just an address, and nearly all the actual risk sits in what answers when you dial it. You can't see the destination before you click, and the malicious traffic doesn't spread evenly across shorteners as a category. It clusters hard around a handful of specific services. A Cofense Intelligence report covering a year of phishing and malware campaigns, July 2024 to June 2025, tracked six commonly abused shortening services and found that 28% of the campaigns delivered malware outright. The rest were credential phishing. That's the honest starting point: most shortened links used in attacks are after a password, not a foothold on your machine, and which specific service carried the link matters more than most people assume.
Is a url shortener safe to click? It depends which one
Treating "url shortener" as a single risk category is where most advice on this topic goes wrong. Google's own shortener, goo.gl, ran for a decade without ever becoming a byword for malware. Bitly, TinyURL, and Rebrandly move enormous volumes of legitimate marketing and social links every day. What the highest-risk services in malicious campaigns actually have in common isn't a shared brand or a shared price point, it's an operational profile, and that profile is worth learning in detail (we cover the format basics separately in what a URL shortener actually is). Call it a url shortener, a short url, a link shortener, doesn't matter. The format is neutral. The specific service is what varies.
The correction almost every article on this topic gets backwards
Search around and you'll find plenty of posts stating that t.ly is "the most abused" URL shortener. That's not quite what the Cofense data says, and the gap matters. t.ly was the most frequently seen shortener across the malicious campaigns Cofense tracked. But its own malware-delivery rate, the share of campaigns using it that actually dropped malware rather than simply phishing for credentials, was under 15%, the lowest of the six services studied. Compare that to goo.su, where 89% of campaigns using it delivered malware, and is.gd, at 49%. Frequency and rate are different measurements. Conflating them inverts the finding entirely.
A shortener can be the one attackers reach for most often simply because it's popular and easy to use, the exact same reasons legitimate marketers reach for it, without being disproportionately dangerous per individual link. If I had to pick the safest of the six services in this dataset, I'd pick t.ly. Its low per-campaign malware rate says more than its appearance count does. If you want to know which shortened links deserve real suspicion on sight, though, goo.su and is.gd are the names the rate data actually points at.
Here's the distinction laid out directly. Cofense's report covered six commonly abused services in total; the numbers below are the ones the report broke out individually.
| Service | How often it appeared in malicious campaigns | Share of those campaigns that delivered malware (vs. phishing) | What that combination means |
|---|---|---|---|
| t.ly | Most frequent of the six | Under 15%, the lowest of the six | Popular with attackers because it's popular generally. Low risk per individual link relative to the others in the study. |
| goo.su | Not the most common | 89%, the highest of the six | Rare in volume, but a malicious campaign using goo.su is overwhelmingly likely to deliver malware, not just serve a phishing form. |
| is.gd | Less frequent than t.ly | 49%, second highest | Roughly half of malicious campaigns using is.gd deliver malware outright, not just a credential-phishing page. |
| The other three services in the study | Lower frequency than t.ly | Not broken out individually in the public report | Present in the same dataset, but Cofense's public report only broke out numbers for the three services above. |
The common trait across the highest-rate services wasn't the brand. It was structure: a free tier, open API access, and minimal identity verification, together letting an attacker script the creation of thousands of malicious short links without a human ever filling out a signup form. That structural point matters more than any single service name, t.ly included.
Why are url shorteners dangerous in the first place
The mechanism here is reputation laundering, not a flaw in the redirect technology itself. Security tools such as email gateways, browser blocklists, and antivirus engines decide what to block mostly by checking domain reputation. bit.ly, tinyurl.com, and t.ly are old, high-traffic domains with clean reputations built over years of legitimate use. A filter checking a link against known-bad domain lists sees a trusted shortener domain and lets it through, because it isn't looking at what sits on the other side of the redirect. The shortener's good name gets borrowed to walk a malicious destination past the checkpoint.
This is also why "bitly virus" shows up as a search at all. Bitly is a real, legitimate company. It hasn't been compromised in any way that would justify the phrase. What people run into is someone else's malicious link, routed through Bitly's infrastructure, which then shows up in a browser warning or antivirus alert with Bitly's domain attached. The alert is accurate about the domain in the address bar. It says nothing about who registered that particular short link, or where it actually goes.
Reputation can fail at the service level too, not just the individual link level. Google Safe Browsing blocklisted the entire bit.ly domain at least once, in 2014, according to security firm Sucuri, after enough malicious links piled up on the service to drag the whole domain's reputation down with them. Every user of a shortening domain shares its reputation, for better and for worse, and a bad enough run of abuse can take the whole domain down along with everyone else's perfectly innocent links.
Why do corporate email filters block short links
Separate from any one service's individual reputation, most corporate email gateways treat shortened links as suspicious by category. This is well documented across security vendor guidance, even without one tidy percentage attached to it. The logic is defensive, not personal: a gateway scanning an email in real time can't know what a t.ly or bit.ly link leads to without following the redirect first, and resolving every redirect in every inbound email, at scale, in real time, is slow and expensive to run. Blocking or flagging the whole category outright is simply cheaper than resolving each link individually. That's also why a shortened link routinely gets flagged by spam filters even when the message behind it is completely legitimate.
An internal link, or a link from a vendor your company actually uses, can get caught by that same filter as a phishing attempt. The filter isn't reading intent. It's reading the presence of a redirect domain it can't immediately verify. If your company keeps flagging or stripping shortened links from mail, that's standard gateway behavior. It isn't a sign something is uniquely wrong with the specific link you sent.
How to check if a shortened link is safe before clicking
- Hover before you click, on desktop. Most browsers and mail clients show the real URL in a status bar or tooltip the moment you hover, without you clicking anything. For a shortened link this at least confirms the redirect address matches the visible text.
- An unshortening, or link-expanding, tool follows the redirect for you and shows the final destination, so your own browser never has to make the request first.
- Check for the service's own preview option. Some shorteners support a preview modifier, appending a plus sign to a bit.ly link, for instance, or a dedicated preview subdomain, that shows the destination on a page before it sends you there.
- VirusTotal is free and takes seconds. Paste the shortened URL in and it checks the link, and the resolved destination, against dozens of security engines at once.
- Look at the address bar after the redirect resolves. If you do click through, check where you actually landed before typing anything into a form. A link that resolves somewhere you didn't expect, especially right before a login page, is the moment to stop and back out.
What separates a legitimate url shortener from a risky one
Whether a link shortener is legit comes down to what it does before a link goes live, not its price tag or its logo. A free tier by itself isn't the problem. Plenty of free, reputable shorteners are perfectly safe to click links from. What actually correlates with abuse, based on the Cofense findings, is a free tier plus open API access plus minimal identity verification, all three present together. That combination is what lets someone script the creation of thousands of malicious links without a human ever proving who they are.
A shortener worth calling legitimate tends to require an account before it will create links. It applies rate limits so one identity can't mass-produce redirects in minutes, screens new links against malware and phishing blocklists at creation time, and keeps a working abuse-report path that actually takes bad links down. None of that shows up in the URL itself, which is the annoying part. It shows up in how hard the service made it for an attacker to automate abuse at scale. That's not something you can eyeball from a single click, but it's the real difference between a shortener that's trustworthy and one that just looks the same on the surface.
Bio-link pages carry the same exposure
The problem isn't unique to classic shorteners. KnowBe4 documented phishing pages built directly on Linktree, hosting fake Microsoft Office 365 login forms behind a trusted-looking bio-link page instead of a shortened URL. The mechanism is identical: a legitimate, well-known platform's domain reputation gets borrowed to host something the platform itself never created and never vetted. Any service that lets a stranger publish a page or a redirect under a shared, reputable domain carries some version of this exposure (if you're weighing bio-link platforms specifically, our comparison of Linktree alternatives covers the security angle too). The fix is the same one that applies to shorteners: verification and a working abuse response on the platform side, plus a habit of checking the actual destination on the visitor side.
What people are actually asking when they search this on reddit
Threads asking whether a particular shortener is safe tend to follow the same shape. Someone got a shortened link from an unfamiliar sender, or a browser flagged one, and they want to know if the brand behind the shortener is the problem. The pattern lines up with what Cofense found: the brand is rarely the useful signal. Bitly, TinyURL, and t.ly move overwhelmingly legitimate traffic, and a shortened link from someone you already trust, in a context you expected it, isn't where the risk concentrates. The risk concentrates in unsolicited links, unexpected senders, and services built specifically to make automated abuse easy. Judge the context and the sender first. Judge the domain of the shortener second.
Where Raydar fits
Raydar is a link platform rather than a classic anonymous shortener, but the underlying question is the same one: does creating a link require an identity, or doesn't it? Raydar's links, whether it's a raydar.bio page or a wrapped link through the general link tool, require an account, which rules out the anonymous, instant, API-driven link creation that Cofense's report ties to the highest abuse rates. That's a meaningfully different starting point than a free, anonymous shortener sitting behind an open API.
It's not a claim of immunity, and there's no reason to pretend otherwise. No platform that lets people create outbound links can promise a link on its domain was never used maliciously. What account-based creation buys is traceability and friction: an abusive link has an owner behind it, and mass-producing links at attacker scale isn't the frictionless process it is on a shortener built for exactly that. If you're evaluating link tools with security in mind, that account-versus-anonymous line is the one worth checking on any platform, ours included, ahead of whatever logo sits on the domain.