Are Short Links Safe? How to Check One Before You Click

Short links have a reputation problem that they mostly don't deserve. The mechanism is harmless: an ordinary short link is a redirect, and a redirect can't do anything a full link couldn't. But short links do hide the destination from a casual glance, and people who send you somewhere you wouldn't choose to go find that useful. So the honest answer to "are short links safe?" is: the link is as safe as its destination, and for most short links you can find out the destination before you go there. This guide shows you how, explains what a responsible shortener does to keep its links trustworthy, and — if you're the one sharing links — how to make yours the kind people click without hesitating.

What a short link actually is

A short link is an address on a shortening service that stands in for a longer one. When you open it, the service's server looks up the long address and replies with an HTTP redirect, and your browser follows it. The full mechanism is a lookup and a redirect, and nothing else: no code runs, no file downloads, nothing is installed. Whatever happens next happens on the destination page, exactly as it would if you'd been given the long address directly.

That framing matters because it separates two different worries:

1. "Is this short link itself dangerous?" Not if it's an ordinary redirect. (A service that shows its own page on the way, such as an ad interstitial, is another matter; see below.)
2. "Is where it sends me dangerous?" Possibly — and that's the question to answer before you click.

Everything below is about the second question.

Four checks before you click

You rarely have to click a short link blind. In rough order of convenience:

1. Use the preview feature

Many services will show you the destination instead of sending you there if you ask. On Xlyl, add a plus sign to the end of any link: xlyl.link/spring+ opens a page that displays the long address, and nothing else. Other services use a similar trick — a trailing +, a -, or a /preview path. If a service offers no way to preview, that's worth noticing.

Two limits. A password-protected Xlyl link is the exception: its preview goes to the password form, and the destination isn't shown to anyone without the password. And a preview shows where a link points right now, not whether that page is safe; the owner can change the destination later.

2. Hover, on a desktop browser

Hover over a link without clicking and look at the bottom-left corner of the window. Browsers show the address the link points to. For a short link this only shows the short address — but it will reveal whether the visible text and the real link disagree, which is the oldest trick in phishing: text that says yourbank.com on a link that goes somewhere else. Hovering can't tell you where a short link finally redirects.

3. Ask the server for the headers only

If you're comfortable with a terminal, curl -I fetches the response headers without following the redirect:

curl -I https://xlyl.link/spring
HTTP/2 302
location: https://example.com/products/spring-collection?utm_source=newsletter

The location line is the address the server sends you to next. For a direct redirect like this one, that's the destination; if the link bounces through more than one service, it's only the first hop. It won't help with a password-protected link (Xlyl's location points at its /protected/… password page), with services that send a page that redirects by script rather than a redirect response, or with servers that don't answer header-only requests.

4. Paste it into an expander

Several websites expand short links for you: paste the short address, they fetch the headers and show you where it leads. They're convenient on a phone, where hovering isn't possible. Prefer one that shows the full chain of redirects, since a link can bounce through more than one service on the way.

What to look at once you can see the destination

Seeing the address is half the job; reading it is the other half. The things that should make you stop:

• The domain isn't what the message implies. A note about your bank that resolves to a domain you've never heard of. Find the real host: take what follows // up to the next /, ? or #; if that contains an @, drop everything up to and including it; drop any :port at the end. So https://trusted.example.attacker.test/login is on attacker.test (trusted.example is only a subdomain of it there), and https://trusted.example@attacker.test/login is on attacker.test too, because everything before the @ is a user name, not the host.
• Look-alike characters. rn for m, a capital I for a lowercase l, an accented letter in a domain that should have none. Phishing domains are built to survive a glance.
• A second redirect to somewhere else. A short link that goes to another short link that goes somewhere else is not automatically bad, but it's a pattern used to evade filters. Expanders that show the chain make this visible.
• A download. If the destination is a file — .exe, .apk, .zip, .scr — and you weren't expecting one, don't.
• Urgency in the message. "Your account will be closed" plus a short link is the standard phishing shape. The short link isn't the tell; the urgency is.

None of these are unique to short links. They're the checks you'd apply to any link; short links just make it more important to look.

What a responsible shortener does about abuse

You can only check links you're sent. The rest of the safety picture is what the shortening service does so that its links aren't used against people in the first place. It's worth knowing, because it's what separates a service worth using from one whose domain will eventually be blocked by browsers and mail filters — taking every honest link with it.

It lets you preview. A service that offers no way to see a destination (other than for links its owners have password-protected) is asking for trust it hasn't earned.

It moderates. Abusive links get reported and removed; the accounts and destination hosts behind them get banned. Xlyl has a report page for exactly this, and administrators can ban a link, its destination host, or an account with a click.

It checks destinations. Known malware and phishing hosts should be refused at creation time, usually against a reputation list such as Google Safe Browsing, which is the same data your browser already uses to warn you. This is imperfect — lists lag reality — but it removes the low-effort abuse that makes up most of the volume.

It doesn't add its own risk. No advertising interstitial between click and destination, because interstitials are where malvertising lives. A free shortener with no ads is safer for your readers than one that pays its bills by putting a page in front of them.

It doesn't keep what it doesn't need. A visitor log with IP addresses is a liability waiting for a breach. Xlyl records each click's time, approximate location, device and source, but never stores visitor IPs.

If you're the one sharing links

Everything so far is about reading links. If you send them — in newsletters, on social media, in print — the question flips: how do you make your short links the kind people click without hesitating?

Use your own domain

go.yourbrand.com/spring tells the reader who sent it before they've read the rest. A generic shortener domain tells them nothing, and if that domain has ever been used for spam, it may tell them something worse. A custom domain puts your name on every link, and it takes one DNS record.

Keep the display text honest

If the visible text is a URL, make it the URL the link goes to. If it's a phrase — "Register for the webinar" — that's fine, as long as the destination is a registration page. The pattern that trains people to distrust links is text that says one thing and a link that goes to another.

Say where it goes

In email and on social, a short link next to a plain description — "Our September menu (PDF)" — tells the reader what to expect before they tap, and gives them what a preview would. This is also good link naming practice: go.cafe.com/menu says more than go.cafe.com/x7Fq2.

Don't put anything sensitive behind obscurity

A random key is not a password. If a document, a recording or a preview shouldn't be forwarded, put a password on the link; the destination is never sent to the browser until the password is right. If it should stop working after the event, give it an expiry.

Prefer HTTPS everywhere

Your short domain should serve HTTPS (Xlyl serves custom domains over HTTPS once their certificate is issued), and so should the destination. A browser warning between the click and your page costs you the visitor.

A note on link previews in chat apps

When you paste a link into a chat app or a social post, the app fetches it to build the preview card. Two consequences:

• The preview shows the destination's title and image, which is usually another way your readers can see where a short link goes before tapping it.
• That fetch counts as a visit on services that don't filter bots. If you ever wonder why a link you only pasted into a group chat already shows clicks, that's why — and it's why honest analytics filter crawlers out.

The short version

• An ordinary short link is a redirect. It can't harm you; the destination might.
• You can usually check the destination first: preview (+ on Xlyl, except for password-protected links), curl -I for the next address, or an expander for the chain. Hovering shows whether the text matches the link.
• Read the domain, not the message. Look-alike characters, unexpected downloads and urgency are the tells.
• Choose services that let you preview, moderate abuse, show no ads, and keep no visitor IP addresses.
• If you share links: your own domain, honest text, a word about where it goes, and a password rather than obscurity for anything private.

Related guides

• How URL shorteners work: redirects, lookups and analytics
• Custom short link best practices: naming and organising
• Short links for social media: a platform-by-platform guide
• Password-protected links · Expiring links