What forwrd.us logs when someone clicks your link

A shortener is not a text-compression tool. It replaces your destination with a key that points at a database row on somebody else's machine, and it puts that machine in the path of every person who clicks. The reader does not connect to the page you sent them to. They connect to us first, we look up the row, and only then do we tell their browser where to go.

That makes every shortener an interception point by construction, including this one. So instead of writing another article about what other services log, here is our own answer, in the same detail we would want from them.

What a click writes to our database

When someone opens a forwrd.us short link, the request hits a route that does three things: it reads the link row for that slug, it checks whether the link is still valid, and it increments the click count. For links owned by an account, it also records the click against a date so the owner can see a per-day chart.

What is in that data:

• The slug that was requested.
• A total click count on the link row.
• For account-owned links, a per-day aggregate of clicks.
• The link's own metadata: destination URL, creation time, expiry and click cap if set, abuse status.

What is not in it:

• No visitor identifier. There is no column that says which browser or person a click came from.
• No tracking cookie set on the redirect path.
• No browser fingerprinting, canvas probing, or device hashing.
• No cross-link correlation, because there is nothing to correlate on.

The practical consequence is the one that matters: we cannot tell you who clicked your link, and neither can anyone who compels us to hand over the table. A count and a date histogram is a genuinely different object from a click log with IP addresses in it.

What the layer underneath us sees anyway

This is the part most privacy pages skip. Our application code can decide what to store, but it cannot decide what an HTTP request contains. Every request that reaches our servers arrives with:

• A source IP address, because TCP requires one to send a response back.
• A User-Agent header, which in 2026 still names the browser family, major version, and operating system class.
• Accept-Language, which is how the site guesses your language before you pick one.
• A Referer header in some cases, when the click came from a link on a page that did not suppress it.
• TLS handshake details, and a timestamp with request-level precision.

Our hosting and edge layer processes those to route, rate-limit, and block abuse, and it keeps short-lived operational logs to do that. We do not feed those logs into analytics, we do not join them to link rows, and we do not use them to build per-visitor profiles. But claiming a redirect leaves no trace anywhere would be false, and a shortener that tells you it sees literally nothing about a click is either running on magic or lying. The honest claim is narrower: nothing about the click is retained in a form that identifies the person, and nothing is sold or shared for advertising. The specifics, including retention windows, are in the privacy policy.

Why we do not offer per-visitor analytics

We could. The data is right there in the request, and "geo and device breakdown per click" is the single most requested feature at every shortener. It is also the feature that turns a link into surveillance infrastructure aimed at people who never agreed to anything. Your reader chose to visit a destination. They did not choose to be measured by a third party on the way.

This is an opinion, and the counter-argument is real: marketers need to know whether a campaign worked, and a click count alone is a blunt instrument. We think destination-side analytics is the right place for that. The site being visited already has a relationship with the visitor, a privacy policy that covers them, and a consent mechanism. Putting the measurement in the redirect hop instead just hides it from everyone.

What we can see, and when we look

Two situations make us look at a link at all. First, abuse: destinations are screened when a link is created, and reported links get reviewed by a human. Our service guidelines describe what gets a link blocked, mainly phishing, malware, and cloaked deception. Second, a support request or a false-positive review, where the owner asks us to look.

Blocking is a destination-side decision, not a visitor-side one. We evaluate the URL, not the person clicking it.

The parts we cannot promise away

Three honest limits.

1. The destination still sees the visitor. Once we issue the redirect, the browser connects to the target site with all the usual headers, and that site can track however it likes. A privacy-respecting hop does not sanitize a hostile destination.
2. Short links hide where they go. That is the feature, and it is also why phishing loves shorteners. We screen destinations and offer a preview page so a cautious reader can resolve a link before opening it, but concealment is inherent to the format.
3. We are a dependency. If forwrd.us disappears, every link pointing through it breaks. That is true of every shortener, and it is the reason we argue against using one when the full URL would have worked. More on that in the piece on link rot.

What to actually do

• Use the full URL wherever length is not a real constraint. It shows the reader where they are going, survives us, and involves no third party.
• Use a short link where length genuinely costs you: print, slides, spoken addresses, QR codes, character-limited fields.
• Shorten anonymously by default. Create an account only when you need ownership features such as custom slugs, statistics, or expiry and click limits.
• When you receive a short link from someone you do not trust, resolve it first rather than opening it.

Frequently asked