What a URL shortener knows about the people who click

Every short link is a request to somebody else's server, and that request carries what any HTTP request carries: the visitor's address, the user agent string their browser sends, the page they came from if the browser passes one, and the time.

The interesting question is not what a redirect can see. It is what it keeps, for how long, and in what form. Those are answerable in specifics rather than in intentions.

Stored

• Time of the request
• Country and city
• Device type, operating system, browser
• Referring domain, without the path
• Whether it was filtered, and the reason
• The address as a salted hash, the salt discarded after about two days

Not stored

• The address itself
• The full referring URL
• Any identifier that would follow a visitor across sites
• Anything naming the person behind the request

The address is hashed, and the salt does not survive

No raw visitor address is stored. Addresses are hashed with SHA-256 and a salt that rotates daily, and the salt lives only in the cache layer, never in the database. It is discarded after about two days.

Both halves matter. Because the salt rotates, the same visitor produces a different hash on Tuesday than on Monday, so nothing here accumulates into a long-lived identifier. Because the salt is discarded and was never written to the database, a copy of the database is not enough to work backwards from a hash to an address, even for the days it covers. A hash of a value drawn from a small space is otherwise guessable, and this is what closes that.

What the hash is for is narrow: recognising a repeat request inside a short window so a retry in the pipeline cannot be counted twice.

The referrer is reduced to a domain

When a browser sends a referring URL, only its host is kept. example.com rather than the full address of the page the visitor was reading.

This is a deliberate reduction rather than a storage decision. The useful signal is which channel a click came from, and the full path of a referring page can carry a search query, a document title or an account identifier that has nothing to do with the link.

What the link's owner can see

The owner of a link sees counts and breakdowns: clicks over time, country, city, device type, operating system, browser, referring domain, whether a click was filtered as automated traffic and the reason, and whether it arrived as a QR scan or an ordinary click.

On the paid plans the individual click records download as CSV: timestamp, country, device, browser, referring host, and the bot flag with its reason. The hash is never in the export. Nothing in the dashboard or the export identifies a person, and nothing follows one visitor between two different customers' links.

How long it is kept

Individual click detail is kept for as long as the plan allows: 30 days on the free plan, 12 months on Pro, 3 years on Business.

Day-by-day totals are kept indefinitely once summarised. That means upgrading later does not retroactively restore per-click detail for days that have already aged out, and it means a long-running link keeps a usable history without keeping every row that produced it.

Cookies

Two, and neither is for measurement: a language preference and a sign-in session, plus whatever the sign-in verification step sets on those. There is no analytics script on this site, no advertising cookie, and nothing that follows a visitor across sites.

Marketing pages are counted in aggregate, per page and per day, with no visitor identifier attached. A person who reads this page and leaves is a number in a daily count and nothing else.

Where the binding statements are

The paragraphs above describe the mechanics. The documents that commit to them are the privacy policy, the cookie policy, and, for visitors and customers in Turkey, the KVKK notice. GDPR and KVKK are the frame this is built inside, and quoting either from memory would be worse than pointing at the pages written to be accurate.