What a shortened link actually knows about you

A shortened link looks like a formatting decision. The URL was ugly and 180 characters long, you ran it through a shortener, and now it is 22 characters and fits on the slide. Nothing about the transaction feels like a privacy choice.

It is one, though, and a fairly consequential one. Shortening a link does not compress it. It replaces your destination with a pointer to a database row on somebody else's server, and inserts that server into the path of every single person who clicks. The reader no longer connects to the page you sent them to; they connect to the shortener, the shortener writes down who they are, and only then does it tell their browser where to go next. You have not shortened a link. You have added a checkpoint.

This piece covers what that checkpoint records, what it can do afterwards that most people never consider, why so much of the internet's link history has already rotted through shorteners, and the narrow set of situations where a short link is genuinely the right answer.

What actually happens when someone clicks

The mechanics are simple, which is part of why they get overlooked. A shortened URL is a domain plus a short code, like example.co/a7Bq2. The code is a key. The shortener's database has a row mapping that key to your destination URL. When a browser requests the short URL, the shortener's server looks up the row and answers with an HTTP redirect - a 301 (permanent), a 302/307 (temporary), or in the worse implementations an HTML page that runs JavaScript and then navigates.

Between the request arriving and the redirect going out, the server has a complete request to log. That includes:

• The IP address, which resolves to a city-level location, an ISP or mobile carrier, and on corporate networks frequently to a specific employer.
• The user agent string - browser, version, rendering engine, operating system, and often device class. Combined with theAccept-Language and Accept headers this is already enough for a coarse fingerprint, as covered in what your browser sends to every website.
• The referrer, when the click came from a link on a web page - which tells the shortener which page, forum thread, or document your link was sitting in.
• The exact timestamp, to the millisecond, which is what makes correlating two separate log sets possible.
• Which link was clicked, and therefore, over time, which links get clicked together by the same IP and device combination.

Commercial shorteners do not treat this as incidental log data. It is the product. The analytics dashboard that shows you clicks by country, device, and hour is the visible slice of it; the invisible slice is that the same records are retained, aggregated across every customer on the platform, and in several documented cases sold, shared with ad partners, or used to build audience segments. A shortener that operates across millions of links on thousands of sites sees a meaningful cross-section of where people go on the internet, keyed by IP.

Many services go a step further and set a cookie on the redirect, or bounce the click through an intermediate tracking domain before releasing it. At that point the shortener is not just logging the click - it is attempting to recognize the same person across every link it handles, on any site, forever.

The destination is editable after you send it

This is the failure mode that gets the least attention and causes the most durable damage. The short code points to a row. Rows are editable.

Whoever controls the account can repoint a live short link at any time, and every future click follows the new destination. The URL in the printed brochure, the academic citation, the archived email, and the QR code on the poster all continue to look identical. There is no version history visible to the reader, no certificate that binds the short code to a destination, and no way to tell from the outside that the link now goes somewhere else.

The account is not the only attack surface. Custom short domains expire. A company that used brnd.co for five years, then let the registration lapse, has handed anyone who buys that domain the ability to answer every historical short link the company ever published. Domain re-registration attacks on abandoned link infrastructure are a recurring, well-documented pattern, and the reason security teams treat expired vanity domains as a genuine incident rather than a housekeeping item.

The practical consequence: a short link is a poor container for anything that needs to still mean the same thing in three years. Citations, legal filings, printed documentation, regulatory disclosures, and anything archival should carry the full URL, ideally alongside an archive snapshot.

Link rot: the shortener is a second point of failure

A normal URL breaks for one reason - the destination moved or went away. A shortened URL breaks for two, because the redirector is an independent dependency that has to keep existing.

The record here is not theoretical. Google stopped creating new goo.gl links in 2019 and began retiring existing ones in 2025, breaking links embedded in millions of documents, support articles, and printed materials. Twitter's t.co has had repeated multi-hour outages that silently made every link on the platform dead. Dozens of smaller services - tr.im, ur1.ca, and a long tail of startups that shut down quietly - took their entire mapping databases offline with them. Bitly's changes to free-tier retention have broken historical links for customers who assumed a short URL was permanent.

Any short link you publish is a bet that a specific company will still be running a specific service, at a specific domain, for as long as your content matters. That is a strange bet to place on infrastructure you adopted to save 150 characters.

The security angle: hiding the destination is the point

The single most useful thing a reader can do before clicking a link is read where it goes. Shortening removes that. This is not a side effect - concealment is the feature, and it is why shorteners feature so heavily in phishing and malware delivery.

The QR code version is worse, because a QR code is a short link rendered as pixels. Nobody can read a QR code with their eyes, the scanning app often opens the destination before showing the URL, and the sticker on the parking meter or the restaurant table can be replaced by anyone with a printer. QR phishing works because the entire trust chain has been replaced by a square of dots. If you generate QR codes, generate them from a URL your audience can also read in plain text - our QR code generator runs entirely in the browser and does not route the code through a redirect service, so the code encodes your actual destination rather than a trackable pointer to it.

If you receive a short link and need to know where it goes, resolve the redirect chain without loading the page. Several shorteners expose a preview mode (adding + to a Bitly link, for instance), and acurl -I against the short URL prints the Location header without executing anything. What you should not do is assume that a recognizable shortener domain means a trustworthy destination. The domain tells you who is doing the redirecting, and nothing at all about where.

What a shortener would look like if it respected you

None of the above means short links are illegitimate. There are real cases - a URL spoken on a podcast, a link printed on a business card, a character-limited SMS, a slide at the back of a room - where a short link is straightforwardly the right tool. The question is what the shortener does with the click.

The properties that actually matter:

• No account required. If there is no signup, there is no identity attached to the link and no profile of the person who created it.
• No click analytics. A shortener that does not offer a dashboard is a shortener that does not need to retain per-click records to sell you the feature.
• A plain HTTP redirect. A 301 or 302 straight to the destination, with no interstitial page, no JavaScript, no tracking pixel, and no cookie set on the way through.
• No third-party scripts anywhere in the redirect path - no ad networks, no analytics vendors, no partner tags.
• An honest statement about logs - what is written down, how long it survives, and who can read it.
• Abuse filtering on destinations, because an open redirector with no controls becomes a phishing tool within days, and that hurts everyone whose links share the domain.

That list is why we built forwrd.us, a no-signup, no-tracking URL shortener made in the USA. It is a plain redirect with no analytics on the click, no account, no cookies, and abuse screening on the destination side. Same reasoning as the tools on this site: do the one job, do not turn the user into the product. We mention it because it is ours and because it is the answer to the question this article raises - not because anyone paid for the placement.

The practical rules

1. Default to the full URL. In email, chat, documents, and on the web, length is not a real cost and the full URL is better in every dimension that matters.
2. Shorten only when length is the actual constraint - print, speech, QR codes, hard character limits.
3. Never shorten something archival. Citations and legal or regulatory references get the full URL plus an archive snapshot.
4. Strip the tracking parameters before you shorten. utm_source, fbclid, gclid, and friends stay inside the short link, invisible to the reader, and hand the destination site an attribution record about whoever clicks.
5. Do not shorten links that are already secrets. A cloud share link, a password reset URL, or a signed download link is a credential. Handing it to a redirect service means handing it to a third party that logs it - the long-form version of the problem covered in why an 'unguessable' share link is not private.
6. Check before you click. Resolve the redirect, or read the preview, before opening a short link you did not create - especially from a QR code.

Where this fits

The pattern is the one that runs through most of what we write about: a convenience feature quietly inserts a third party into a transaction that did not need one, and the cost is invisible because it lands on the reader rather than the person who chose the tool. The same shape shows up in cloud share links, in what your browser sends to every site, in the VPN industry's core trade of moving who can see your traffic rather than removing them, and in what 'delete' actually does once a copy has been handed to somebody else's server.

Privvert's own tools run in the browser for the same reason: the fewer parties in the path, the fewer parties keeping records. The reasoning is on the privacy page, and the rest of the guides are on the blog.